[OE-core] Schizophrenic package management

[Mark Hatle]

On 4/3/12 1:21 PM, Chris Larson wrote:
> On Tue, Apr 3, 2012 at 11:17 AM, Mark Hatle<mark.hatle at windriver.com>  wrote:
>> On 4/3/12 1:07 PM, Gary Thomas wrote:
>>>
>>> On 2012-04-03 12:03, Mark Hatle wrote:
>>>>
>>>> On 4/3/12 12:52 PM, Gary Thomas wrote:
>>>>>
>>>>> Why are both opkg-native and rpm-native needed to build images?
>>>>> When I asked this previously, I was told that rpm was used because
>>>>> it has superior dependency tracking. Fair enough (I guess), but
>>>>> then why is opkg required if I build an image using
>>>>> PACKAGE_CLASSES = "package_rpm"
>>>>>
>>>>
>>>> rpm-native is used for internal dependency scanning. The exact tool is
>>>> "rpmdeps". These dependencies may or may not be rolled up into package level
>>>> dependencies by the packaging
>>>> tool (which may be opkg, deb or rpm). (see package.bbclass)
>>>>
>>>> opkg-native is used for handling alternatives and similar during
>>>> packaging and image creation. So it's also needed.
>>>
>>>
>>> Why?  Surely one or the other should be useful for this.  I'm sure
>>> that RedHat doesn't need opkg to build their images...
>>
>>
>> (repeating Paul for the sake of threads when someone searches)
>>
>> OE uses the update-alternatives method of handing multiple packages that
>> provide the same functionality.  Packaging systems themselves don't do this,
>> the helpers do.
>>
>> opkg-native provides update-alternatives-cworth (according to Paul E) and
>> that is needed by the other components in the system to determine which
>> version of a particular piece of functionality is needed during image
>> creation.
>>
>> There is an "alternative" update-alternatives package, but I don't believe
>> there is a native version.  If anything that is all that should be
>> required...
>>
>> (And RedHat based linux distributions don't have any concept of
>> alternatives. They generally decide which binary package will provide the
>> functionality and that is the defacto standard for a given release.  OE on
>> the other hand is closer to Debian based systems in that regard.  We can
>> build multiple packages that may provide the same functionality, then it's
>> up to the package install time to determine which version of the
>> functionality is used as the default.)
>
> What's quite interesting to me is that chkconfig has an alternatives
> command in its source tree which seems to behave just like
> update-alternatives and is written in C, and includes a man page. See
> http://www.fastcoder.net/downloads/chkconfig-1.3.30c.tar.gz -
> ./alternatives.c, ./alternatives.8. I'd suggest we look closer at this
> rather than continuing to rely on update-alternatives-cworth.

I think that is an excellent idea.  I'd like to get away from the bundled 
update-alternatives (or even the alternative, update-alternatives) to something 
like chkconfig.

Can you file an enhancement bug on the bugzilla.yoctoproject.org website?  I'll 
be happy to look into this after the current stabilization cycle.

--Mark