Schizophrenic package management

Schizophrenic package management

[Gary Thomas]

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"

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Schizophrenic package management

[Mark Hatle]

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.

I don't believe opkg, or rpm are needed on the target image though, unless of 
course you select one of them as the packaging type and you want target package 
management.

--Mark

Re: Schizophrenic package management

[Paul Eggleton]

On Tuesday 03 April 2012 11:52:07 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"

On the face of it it seems odd; however the reason you get both built no 
matter which you choose is we need some component of each one regardless of 
what packaging system is chosen:

* opkg is needed to provide update-alternatives-cworth
* rpm is needed to provide rpmdeps

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Schizophrenic package management

[Gary Thomas]

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

>
> I don't believe opkg, or rpm are needed on the target image though, unless of course you select one of them as the packaging type and you want target package management.

Yes, of course.  I just don't see the need to have to build both
just to create my image.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Schizophrenic package management

[Mark Hatle]

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.)

--Mark

>>
>> I don't believe opkg, or rpm are needed on the target image though, unless of course you select one of them as the packaging type and you want target package management.
>
> Yes, of course.  I just don't see the need to have to build both
> just to create my image.
>

Re: Schizophrenic package management

[Chris Larson]

On Tue, Apr 3, 2012 at 11:17 AM, Mark Hatle <mark.hatle@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

Re: Schizophrenic package management

[Gary Thomas]

On 2012-04-03 12:17, Mark Hatle 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.)

Thanks for the explanation.  Sorry to be stubborn on this, it just seems
really convoluted that neither opkg nor rpm are sufficient to complete
the build, but I'll accept it as so.

>>>
>>> I don't believe opkg, or rpm are needed on the target image though, unless of course you select one of them as the packaging type and you want target package management.
>>
>> Yes, of course. I just don't see the need to have to build both
>> just to create my image.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: 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@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

Re: Schizophrenic package management

[Steffen Sledz]

On 03.04.2012 20:17, Mark Hatle wrote:
> On 4/3/12 1:07 PM, Gary Thomas wrote:
> ...
> (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.)

FYI: openSUSE 12.1 (rpm-based) uses

Name        : update-alternatives
Version     : 1.15.8.10
Release     : 9.1.2
Architecture: x86_64
Install Date: Fri Nov 18 12:16:48 2011
Group       : System/Management
Size        : 67090
License     : GPLv2+
Signature   : RSA/SHA256, Sat Oct 29 12:13:51 2011, Key ID b88b2fd43dbdc284
Source RPM  : update-alternatives-1.15.8.10-9.1.2.src.rpm
Build Date  : Sat Oct 29 12:13:28 2011
Build Host  : build16
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://ftp.de.debian.org/debian/pool/main/d/dpkg/
Summary     : Maintain symbolic links determining default commands
Description :
update-alternatives creates, removes, maintains and displays
information about the symbolic links comprising the alternatives
system. It is possible for several programs fulfilling the same or
similar functions to be installed on a single system at the same time.
For example, many systems have several text editors installed at once.
This gives choice to the users of a system, allowing each to use a
different editor, if desired, but makes it difficult for a program to
make a good choice of editor to invoke if the user has not specified a
particular preference.
Distribution: openSUSE 12.1

> ...

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: Schizophrenic package management

[Colin Walters]

On Tue, 2012-04-03 at 13:17 -0500, Mark Hatle wrote:

> (And RedHat based linux distributions don't have any concept of alternatives. 

True...until about 10 years ago.

    Sun Jan 27 2002 Erik Troan <ewt@redhat.com>
    - reimplemented update-alternatives as just alternatives

http://pkgs.fedoraproject.org/gitweb/?p=chkconfig.git;a=commit;h=e68fd156aa94245e111a50ff4bee31f304b52727