Re: opkg dependencies and update-alternatives

[ChenQi <Qi.Chen@windriver.com>]

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