opkg dependencies and update-alternatives

opkg dependencies and update-alternatives

[Paul Barker]

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,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: opkg dependencies and update-alternatives

[ChenQi]

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.

Thanks,
Chen Qi

Re: opkg dependencies and update-alternatives

[Paul Barker]

On 18 November 2013 02:54, ChenQi <Qi.Chen@windriver.com> 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.
>
> Thanks,
> Chen Qi

I've added the info from my email to the bug and opened an opkg bug
for the problems with changing the link name during a package upgrade:
https://code.google.com/p/opkg/issues/detail?id=113

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: opkg dependencies and update-alternatives

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

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@openedhand.com>
Date:   Wed Mar 19 15:36:01 2008 +0000

    update-alternatives-cworth: dropped as they are now generated with opkg recipe

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: opkg dependencies and update-alternatives

[Richard Purdie]

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@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?

Cheers,

Richard

Re: opkg dependencies and update-alternatives

[Paul Barker]

On 18 November 2013 11:57, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2013-11-18 at 12:40 +0100, Martin Jansa wrote:
>>
>> 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@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'd be quite happy to break it out into a separate repo. I think
that's better than direct inclusion into oe-core so that it remains
easily usable by non-oe systems.

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

The dpkg version does have more features but the dpkg recipe in
oe-core says that it can't provide
"virtual/update-alternative-native". I think the reason there is that
it doesn't support installing to an offline target filesystem. I don't
know how the performance compares but I don't think it's critical as
it isn't a program that will be running very often on a target. The
opkg version is probably more lightweight as it is a short shell
script vs the 2,700 lines of C which make up the dpkg version.

There is also an "alternatives" program in chkconfig which is listed
as a possible provider of "virtual/update-alternatives" but again,
trying to use in causes a dependency loop. I haven't given this
version more than a quick glance though.

Personally I'd say the dpkg version looks the best as it allows a user
or script to query or change which alternative is selected whereas the
opkg version only allows alternatives to be installed or removed. It
would just need someone with the time to look into how it can be made
to install links to a target filesystem rather than to the host
filesystem. Unfortunately that isn't me at the moment.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: opkg dependencies and update-alternatives

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]

On Mon, Nov 18, 2013 at 03:31:09PM +0000, Paul Barker wrote:
> On 18 November 2013 11:57, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Mon, 2013-11-18 at 12:40 +0100, Martin Jansa wrote:
> >>
> >> 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@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'd be quite happy to break it out into a separate repo. I think
> that's better than direct inclusion into oe-core so that it remains
> easily usable by non-oe systems.

What about including it in opkg-utils repo? And maybe even providing u-a
by opkg-utils.bb?

opkg-utils.bb doesn't have any DEPENDS (Only python RDEPENDS) so it
would be good compromise between opkg and completely new recipe.

> >
> > 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?
> >
> 
> The dpkg version does have more features but the dpkg recipe in
> oe-core says that it can't provide
> "virtual/update-alternative-native". I think the reason there is that
> it doesn't support installing to an offline target filesystem. I don't
> know how the performance compares but I don't think it's critical as
> it isn't a program that will be running very often on a target. The
> opkg version is probably more lightweight as it is a short shell
> script vs the 2,700 lines of C which make up the dpkg version.
> 
> There is also an "alternatives" program in chkconfig which is listed
> as a possible provider of "virtual/update-alternatives" but again,
> trying to use in causes a dependency loop. I haven't given this
> version more than a quick glance though.
> 
> Personally I'd say the dpkg version looks the best as it allows a user
> or script to query or change which alternative is selected whereas the
> opkg version only allows alternatives to be installed or removed. It
> would just need someone with the time to look into how it can be made
> to install links to a target filesystem rather than to the host
> filesystem. Unfortunately that isn't me at the moment.
> 
> -- 
> Paul Barker
> 
> Email: paul@paulbarker.me.uk
> http://www.paulbarker.me.uk

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: opkg dependencies and update-alternatives

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Mon, Nov 18, 2013 at 9:20 AM, Martin Jansa <martin.jansa@gmail.com>wrote:

> > There is also an "alternatives" program in chkconfig which is listed
> > as a possible provider of "virtual/update-alternatives" but again,
> > trying to use in causes a dependency loop. I haven't given this
> > version more than a quick glance though.
> >
>

At Mentor, we’ve been using
https://github.com/MentorEmbedded/meta-mentor/blob/master/recipes/chkconfig/chkconfig-alternatives_1.3.59.bb
for
a while now with good results, for what it’s worth.

https://github.com/MentorEmbedded/meta-mentor/blob/master/conf/distro/include/mel.conf#L140-L144
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1582 bytes --]

Re: opkg dependencies and update-alternatives

[Paul Barker]

On 18 November 2013 16:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 03:31:09PM +0000, Paul Barker wrote:
>> On 18 November 2013 11:57, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> >
>> > 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'd be quite happy to break it out into a separate repo. I think
>> that's better than direct inclusion into oe-core so that it remains
>> easily usable by non-oe systems.
>
> What about including it in opkg-utils repo? And maybe even providing u-a
> by opkg-utils.bb?
>
> opkg-utils.bb doesn't have any DEPENDS (Only python RDEPENDS) so it
> would be good compromise between opkg and completely new recipe.
>

I think this is the most sensible option. If u-a is put into a
separate package it shouldn't need any RDEPENDS either.

I'll send in the patches I have for oe-core, they'll need a little
more testing before they're ready to be pushed to the mainline though.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: opkg dependencies and update-alternatives

[Richard Purdie]

On Wed, 2013-11-20 at 16:24 +0000, Paul Barker wrote:
> On 18 November 2013 16:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Mon, Nov 18, 2013 at 03:31:09PM +0000, Paul Barker wrote:
> >> On 18 November 2013 11:57, Richard Purdie
> >> <richard.purdie@linuxfoundation.org> wrote:
> >> >
> >> > 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'd be quite happy to break it out into a separate repo. I think
> >> that's better than direct inclusion into oe-core so that it remains
> >> easily usable by non-oe systems.
> >
> > What about including it in opkg-utils repo? And maybe even providing u-a
> > by opkg-utils.bb?
> >
> > opkg-utils.bb doesn't have any DEPENDS (Only python RDEPENDS) so it
> > would be good compromise between opkg and completely new recipe.
> >
> 
> I think this is the most sensible option. If u-a is put into a
> separate package it shouldn't need any RDEPENDS either.
> 
> I'll send in the patches I have for oe-core, they'll need a little
> more testing before they're ready to be pushed to the mainline though.

Having a python RDEPENDS means that will turn into python-native and
that is a pretty heavy dependency in its own right :(

Cheers,

Richard

Re: opkg dependencies and update-alternatives

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]

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@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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]