[oe] reverting some csets that kill package upgrade paths
Koen Kooi
k.kooi at student.utwente.nl
Fri Apr 24 17:32:57 UTC 2009
Hi,
Recently the e17 people made a change to how libtool names their
libraries by poking in some magic string (ver-pre-svn-00) into SONAME.
This has some implications for OE, namely that you get the old *and* new
lib in your rootfs. There was one bug that killed everything at runtime:
http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=1496aea759adb716453d0fbf85795a5a6e914484
So after that cset you'd get a completely working rootfs again with e17
stuff.
Today a few csets have been pushed that break things horribly:
http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=6898f8ca089d35109b3652d640ebb907d8115736
http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=8101ad8e1229b3b9f8aa0be0fdc262b5283034d0
http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=80c85e0af3865710a189ba536022d326fa996d26
Let's take a look at the generated packages:
before: libecore-evas-ver-pre-svn-00-0_0.9.9.050+svnr40247-r3.1_armv7a.ipk
after: libecore-ver-pre-svn-00-lib-evas_0.9.9.060+svnr40247-r3.1_armv7a.ipk
So suddenly the library packages (or plugin packages, but no difference
in this case) have a new name, but don't set RPROVIDES or RREPLACES to
the old packages containing *the same files*. This means that 'opkg
install <foo>' or 'opkg upgrade' doesn't work anymore. It will abort
saying to package <foo> wants to overwrite files belonging to <bar>.
Depending on the way you build your images in OE, your build will break.
My position is that breaking upgrade patch unacceptable without prior
notice and that the above 3 csets get reverted ASAP.
The changes in question are not intrinsically bad, and the autosplitting
is way better than manually poking at FILES_foo, but right now they
break way too much at runtime.
regards,
Koen
More information about the Openembedded-devel
mailing list