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