Schizophrenic package management
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"
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 6 lines · 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"
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
Quoted 8 lines · Mark Hatle
Quoted 6 lines · 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"
Quoted 4 lines
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...
Quoted 2 lines
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.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 9 lines · Gary Thomas
Quoted 8 lines · Mark Hatle
Quoted 6 lines · 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"
Quoted 7 lines
Quoted 4 lines
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
Quoted 6 lines
Quoted 2 lines
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.
Quoted 41 lines · Mark Hatle
Quoted 17 lines · Gary Thomas
Quoted 15 lines · Mark Hatle
Quoted 7 lines · 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"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)Quoted 6 lines
Quoted 2 lines
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...
Quoted 7 lines
(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.
Signature · 1 line
Christopher Larson
Quoted 50 lines · Chris Larson
Quoted 41 lines · Mark Hatle
Quoted 17 lines · Gary Thomas
Quoted 15 lines · Mark Hatle
Quoted 7 lines · 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"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)Quoted 6 lines
Quoted 2 lines
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...
Quoted 7 lines
(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.)
Quoted 6 lines
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
Quoted 22 lines · Mark Hatle
Quoted 9 lines · Gary Thomas
Quoted 8 lines · Mark Hatle
Quoted 6 lines · 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"Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 9 lines · Mark Hatle
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
Quoted 1 line
...
Steffen
Signature · 7 lines
DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058
Quoted 1 line · Mark Hatle
(And RedHat based linux distributions don't have any concept of alternatives.
True...until about 10 years ago.
Sun Jan 27 2002 Erik Troan <[email protected]>
- reimplemented update-alternatives as just alternatives
Quoted 5 lines · 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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre