On 4/3/12 1:21 PM, Chris Larson wrote:
On Tue, Apr 3, 2012 at 11:17 AM, Mark Hatle<mark.ha...@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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
