[OE-core] opkg dependencies and update-alternatives

[Martin Jansa]

On Mon, Nov 18, 2013 at 03:31:09PM +0000, Paul Barker wrote:
> On 18 November 2013 11:57, Richard Purdie
> <richard.purdie at linuxfoundation.org> 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 <hrw at openedhand.com>
> >> 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: paul at paulbarker.me.uk
> http://www.paulbarker.me.uk

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131118/c5b057ff/attachment-0002.sig>