OEDEM 2009 summary: Package management

OEDEM 2009 summary: Package management

[Phil Blundell]

This was the last session of the OEDEM schedule and the number of
participants was much reduced compared to the previous ones.  Partly as
a result of that it was also very short.

Key issue: opkg is the defacto standard for package management in
OE-derived distros but its quality is perceived as low.  What can we do
about this?

RP: not many problems encountered with opkg in poky

PB: opkg generally performs OK within its own "comfort envelope".  Main
triggers for badness seem to be online upgrades, and the requirement to
make a decision between two alternatives.  If you stay away from those
things and use opkg only for image construction then it is not so bad.

Can we fix opkg to make it work better?

- many have tried and not gotten anywhere, e.g. openmoko spent a while
hacking on it but many problems remain.  Suspect that maybe the codebase
in its current form is just unfixable and it would be better to throw it
away.

- nonetheless, Graham Gower is trying to repair it.  All strength to his
elbow!

Can we use something else instead?

- dpkg: does its job well but this is only half the problem (and opkg is
not so bad at this part anyway).  Not obvious that this would help very
much.  Note that busybox includes a dpkg implementation nowadays as
well.

- apt: high quality but footprint is too big.  written in C++, which is
a big deal for folks who would not otherwise be shipping libstdc++.
Run-time memory requirements also larger than we think we can tolerate
on small devices.

- others?  No obvious candidates come to mind.  

Can we do something better for image construction, at least?

- when building an initial rootfs, can bring the whole power of the
build machine to bear on the problem.  Can we use another tool to
resolve dependencies, then just pass a flat package list to opkg/dpkg
for installation?

- it would be nice to leverage bitbake's knowledge of the dependency
graph if this is possible

- RP: it is not possible, bitbake thinks only in terms of task
dependencies and doesn't care about runtime ones per se.  Metadata for
output packages is not re-injected into bitbake core and hence not
usable for this purpose.

- PB: Drat.

- could write another program to do this but it would not be trivial

Conclusions

- right now, opkg seems to be as good as it gets

- encourage folks to write replacements, maybe OE e.V. can offer
bounties for this at some point

- improving image construction is a worthwhile goal in itself: not
everybody has the capability/desire to do online upgrades.

Re: OEDEM 2009 summary: Package management

[Martin Jansa]

On Wed, Nov 11, 2009 at 05:12:01PM +0000, Phil Blundell wrote:
> This was the last session of the OEDEM schedule and the number of
> participants was much reduced compared to the previous ones.  Partly as
> a result of that it was also very short.
> 
> Key issue: opkg is the defacto standard for package management in
> OE-derived distros but its quality is perceived as low.  What can we do
> about this?

Today I've "fixed" one problem we had with opkg in shr.

opkg installs own version of update-alternatives

its the same script as the one packaged as update-alternatives-cworth

its installed to /usr/bin (update-alternatives-cworth is using
/usr/sbin so in PATH is after version from opkg)

I've patch for update-alternatives-cworth to use alternative which was
installed last if there is no alternative with higher priority (see 
http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=6c1ed757c1498aff5b4b1b876332d2981f0855a1
)

And it was really confusing to have 2 simillar update-alternatives
scripts in image.

So it should be removed from opkg as I did in
http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=376cca189eed7a13de5a348e630c0af274c4704b
http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=416f6e5f5cfa23f0b3ae731af5c2a1dcd1e27189

or opkg should provide virtual/update-alternatives as distros are using
preferred_provider for that already.


-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: OEDEM 2009 summary: Package management

[Martin Jansa]

On Wed, Nov 11, 2009 at 9:33 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> On Wed, Nov 11, 2009 at 05:12:01PM +0000, Phil Blundell wrote:
> > This was the last session of the OEDEM schedule and the number of
> > participants was much reduced compared to the previous ones.  Partly as
> > a result of that it was also very short.
> >
> > Key issue: opkg is the defacto standard for package management in
> > OE-derived distros but its quality is perceived as low.  What can we do
> > about this?
>
> Today I've "fixed" one problem we had with opkg in shr.
>
> opkg installs own version of update-alternatives
>
> its the same script as the one packaged as update-alternatives-cworth
>
> its installed to /usr/bin (update-alternatives-cworth is using
> /usr/sbin so in PATH is after version from opkg)
>
> I've patch for update-alternatives-cworth to use alternative which was
> installed last if there is no alternative with higher priority (see
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=6c1ed757c1498aff5b4b1b876332d2981f0855a1
> )
>
> And it was really confusing to have 2 simillar update-alternatives
> scripts in image.
>
> So it should be removed from opkg as I did in
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=376cca189eed7a13de5a348e630c0af274c4704b
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=416f6e5f5cfa23f0b3ae731af5c2a1dcd1e27189
>
> or opkg should provide virtual/update-alternatives as distros are using
> preferred_provider for that already.


with update-alternatives removed from opkg-native I noticed that

virtual/update-alternatives-native defined in sane-feed-ipk.inc is not
installed at all before building any image, so created image is not
bootable, because there are missing links for busybox and kernel image etc.

where should be "DEPENDS = virtual/update-alternatives-native" to make sure,
that it is pulled before any package calls update-alternatives?

maybe tasks/task-boot.bb where is just virtual/kernel now?

Regards,

Re: OEDEM 2009 summary: Package management

[Florian Boor]

Hi,

Phil Blundell schrieb:
> PB: opkg generally performs OK within its own "comfort envelope".  Main
> triggers for badness seem to be online upgrades, and the requirement to
> make a decision between two alternatives.  If you stay away from those
> things and use opkg only for image construction then it is not so bad.

I have not tried much online upgrades for some time but I ran into package
selection issues lately. We always suffered from the problem that opkg failed
with an error message if the same package was available with two different
architectures... but this is fixed upstream now.

greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en