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
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
