Re: reverting some csets that kill package upgrade paths

[Philip Balister <philip@balister.org>]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

Koen Kooi wrote:
> 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.

I'm not opposed to breaking upgrade paths in .dev. After all .stable 
exists to provide a sane base for supplying packages to users.

But, there are issues with breaking the upgraded paths in dev that do 
impact supporting stable. Once the upgrade path is broken in dev, it is 
much harder to use dev to test changes before they are integrated into 
stable. At this point in time, I feel it is to early to break upgrading 
e17 since it is undergoing active development and is being supported in 
both dev and stable at the moment.

This email is not an ack of the revert, but I encourage people to think 
about this issue and make a decision how best to move forward with e17 
support in dev so that dev can support stable for a while.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]