[OE-core] Schizophrenic package management

Chris Larson clarson at kergoth.com
Tue Apr 3 18:21:15 UTC 2012


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.
-- 
Christopher Larson




More information about the Openembedded-core mailing list