On 13 February 2014 11:38, Richard Purdie <[email protected]> wrote: > On Wed, 2014-02-12 at 17:40 +0200, Laurentiu Palcu wrote: >> On Wed, Feb 12, 2014 at 03:07:31PM +0000, Phil Blundell wrote: >> > On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote: >> > > * /usr/lib/opkg is where the alternatives go; >> > >> > Isn't that a bug? >> I'm far from being an expert in opkg or update-alternatives, but, >> looking in /usr/bin/update-alternatives I can see: >> >> # admin dir >> ad="$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives" >> >> Isn't that expected since the u-a provider is opkg-utils recipe? > > Its certainly desirable to have one set of alternatives files on a > multilib system, not two. The variables/paths could probably do with > being better however I've prefer not to trigger autobuilder failures on > this until that gets resolved so I did take this. > > Cheers, > > Richard >
I should add some flexibility here. The problem is opkg-utils doesn't know what value OPKGLIBDIR has in the opkg recipe. It also isn't processed by a configure script to replace variables as it was in the opkg recipe. I'll have a think about a cleaner upgrade path for opkg and opkg-utils. I'd like to have a postinstall script compare the old and new OPKGLIBDIR paths and move data if needed. That would let me move everything from /usr/lib to /var/lib. -- Paul Barker Email: [email protected] http://www.paulbarker.me.uk _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
