From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Schizophrenic package management
Date: Tue, 3 Apr 2012 13:17:18 -0500 [thread overview]
Message-ID: <4F7B3EAE.2000301@windriver.com> (raw)
In-Reply-To: <4F7B3C75.5030200@mlbassoc.com>
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.
>
next prev parent reply other threads:[~2012-04-03 18:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-03 17:52 Schizophrenic package management Gary Thomas
2012-04-03 18:03 ` Mark Hatle
2012-04-03 18:07 ` Gary Thomas
2012-04-03 18:17 ` Mark Hatle [this message]
2012-04-03 18:21 ` Chris Larson
2012-04-03 18:24 ` Mark Hatle
2012-04-03 18:23 ` Gary Thomas
2012-04-04 10:23 ` Steffen Sledz
2012-04-04 19:01 ` Colin Walters
2012-04-03 18:05 ` Paul Eggleton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F7B3EAE.2000301@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.