[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