[OE-core] opkg dependencies and update-alternatives

[Martin Jansa]

On Mon, Nov 18, 2013 at 11:57:32AM +0000, Richard Purdie wrote:
> On Mon, 2013-11-18 at 12:40 +0100, Martin Jansa wrote:
> > On Mon, Nov 18, 2013 at 10:54:47AM +0800, ChenQi wrote:
> > > On 11/18/2013 02:57 AM, Paul Barker wrote:
> > > > Hi all,
> > > >
> > > > I've been trying to add PACKAGECONFIG options to opkg and have ran
> > > > into a dependency loop whilst building with certain options. Enabling
> > > > curl support within opkg requires a dependency on curl. curl in turn
> > > > depends on ncurses (via a few intermediate dependencies) and ncurses
> > > > uses update-alternatives causing a dependency on
> > > > virtual/update-alternatives.
> > > > PREFERRED_PROVIDER_virtual/update-alternatives is set to "opkg" in
> > > > meta/conf/distro/include/default-providers.inc and so we have a
> > > > dependency loop if curl is enabled via the new PACKAGECONFIG options
> > > > for opkg.
> > > >
> > > > I can cause the same dependency loop by setting
> > > > PREFERRED_PROVIDER_virtual/update-alternatives to "dpkg" as dpkg
> > > > directly depends on ncurses (which uses update-alternatives). So if
> > > > someone wanted to use the more powerful update-alternatives from dpkg
> > > > on a target system it doesn't look like that is currently possible.
> > > >
> > > > This places quite a constraint on whichever recipe PROVIDES
> > > > update-alternatives. Going forward I'm hoping to use libarchive within
> > > > opkg and libarchive depends on bzip2 by default which uses
> > > > update-alternatives, which would cause the same problem.
> > > >
> > > > Does anyone have any clever solutions to this? Perhaps we could split
> > > > update-alternatives off into its own recipe which should be dependent
> > > > on very little, allowing opkg a little more freedom in its
> > > > dependencies.
> > > >
> > > > Thanks,
> > > >
> > > 
> > > I opened a bug some time ago for this update-alternative problem.
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=4836
> > > 
> > > It would be really helpful if you could add some input in the comments 
> > > of that bug.
> > 
> > FWIW: current u-a implementation provided by opkg is in OE-classic and
> > was in older poky/oe-core provided also in standalone recipe
> > update-alternatives-cworth
> > 
> > http://git.openembedded.org/openembedded/tree/recipes/update-alternatives/update-alternatives-cworth_0.99.154.bb
> > 
> > commit 44b538eedab7c255051fa3375f9f2439cd2db3dd
> > Author: Marcin Juszkiewicz <hrw at openedhand.com>
> > Date:   Wed Mar 19 15:36:01 2008 +0000
> > 
> >     update-alternatives-cworth: dropped as they are now generated with opkg recipe
> 
> Turning this back into a standalone recipe might be worthwhile and seems
> like the best way to address the problems.
> 
> Paul: Have you any opinion of moving update-alternatives to its own
> repository separate from opkg? or just check it into OE-Core as its just
> a single script? Its not as if it really needs much from opkg at this
> point?
> 
> I'm also wondering how it compares to the dpkg version (which is C
> iirc). Should we switch to that? Does it give better performance?

Just note from someone who broke all upgrade paths in OE-classic and
then had to add hack to resolve upgrade paths:
http://git.openembedded.org/openembedded/tree/recipes/opkg/update-alternatives-merge.inc

Changing u-a implementation is very tricky for people who care about
upgrade paths.
Changing alternatives directory when switching from cworth to opkg, i.e.
from
${prefix}/lib/ipkg
to
${prefix}/lib/opkg
was fatal for all systems depending on busybox/coreutils - first
upgrade selected wrong alternatives, because it didn't know about
already installed alternatives in old directory.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131118/627cb8c2/attachment-0002.sig>