[OE-core] 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 at paulbarker.me.uk
http://www.paulbarker.me.uk