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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
