On Mon, Nov 18, 2013 at 03:31:09PM +0000, Paul Barker wrote: > On 18 November 2013 11:57, Richard Purdie > <[email protected]> wrote: > > On Mon, 2013-11-18 at 12:40 +0100, Martin Jansa wrote: > >> > >> FWIW: current u-a implementation provided by opkg is in OE-classic and > >> was in older poky/oe-core provided also in standalone recipe > >> update-alternatives-cworth > >> > >> http://git.openembedded.org/openembedded/tree/recipes/update-alternatives/update-alternatives-cworth_0.99.154.bb > >> > >> commit 44b538eedab7c255051fa3375f9f2439cd2db3dd > >> Author: Marcin Juszkiewicz <[email protected]> > >> Date: Wed Mar 19 15:36:01 2008 +0000 > >> > >> update-alternatives-cworth: dropped as they are now generated with > >> opkg recipe > > > > Turning this back into a standalone recipe might be worthwhile and seems > > like the best way to address the problems. > > > > Paul: Have you any opinion of moving update-alternatives to its own > > repository separate from opkg? or just check it into OE-Core as its just > > a single script? Its not as if it really needs much from opkg at this > > point? > > I'd be quite happy to break it out into a separate repo. I think > that's better than direct inclusion into oe-core so that it remains > easily usable by non-oe systems.
What about including it in opkg-utils repo? And maybe even providing u-a by opkg-utils.bb? opkg-utils.bb doesn't have any DEPENDS (Only python RDEPENDS) so it would be good compromise between opkg and completely new recipe. > > > > I'm also wondering how it compares to the dpkg version (which is C > > iirc). Should we switch to that? Does it give better performance? > > > > The dpkg version does have more features but the dpkg recipe in > oe-core says that it can't provide > "virtual/update-alternative-native". I think the reason there is that > it doesn't support installing to an offline target filesystem. I don't > know how the performance compares but I don't think it's critical as > it isn't a program that will be running very often on a target. The > opkg version is probably more lightweight as it is a short shell > script vs the 2,700 lines of C which make up the dpkg version. > > There is also an "alternatives" program in chkconfig which is listed > as a possible provider of "virtual/update-alternatives" but again, > trying to use in causes a dependency loop. I haven't given this > version more than a quick glance though. > > Personally I'd say the dpkg version looks the best as it allows a user > or script to query or change which alternative is selected whereas the > opkg version only allows alternatives to be installed or removed. It > would just need someone with the time to look into how it can be made > to install links to a target filesystem rather than to the host > filesystem. Unfortunately that isn't me at the moment. > > -- > Paul Barker > > Email: [email protected] > http://www.paulbarker.me.uk -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
