[oe] 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.