[oe] reverting some csets that kill package upgrade paths

[Marcin Juszkiewicz]

Dnia piątek, 24 kwietnia 2009 o 19:32:57 Koen Kooi napisał(a):

> 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=149
>6aea759adb716453d0fbf85795a5a6e914484

> So after that cset you'd get a completely working rootfs again with
> e17 stuff.

First I want to say that I am total ignorant when it comes to E17. I 
have it installed on Beagleboard just because it is part of 
'beagleboard-demo-image' which I installed. As it I did not built it 
during last 2 years on any of my machines. Thats some kind of  
background introduction.

> Today a few csets have been pushed that break things horribly:
>
> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=
> 6898f8ca089d35109b3652d640ebb907d8115736

I see edje RRECOMMENDS adapted to other changes here (not counting PV 
upgrades).

> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=
> 8101ad8e1229b3b9f8aa0be0fdc262b5283034d0

This one looks quite sane.

> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=
> 80c85e0af3865710a189ba536022d326fa996d26

s/libevas/evas - but should not debian.bbclass take care of that? 

> 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 why not change call to populate_packages_prepend() to make old names 
again? That way we will get autosplit (which is good) and old names 
(which will keep some kind of upgrade path).

> 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.

Provide a patch which will add such ones? We have many developers in OE 
- some of them use OE for development of software (Mickeyl for example), 
some use it to build software for distribution users (Koen), some use it 
for different purposes (me for example). It is hard to make all of them 
happy with each commit. This is .dev tree - things will break and we can 
not stop it (we have stable/2009 for not breaking changes). 

The real problem is not how to keep quality after each commit but how to 
keep it overall. If something break do not automatically shout "you 
moron, you broke OE" - it is not SouthPark and OE is not Kenny. So when 
problem shows we need to discuss how to fix it instead of shouting at 
each other. Otherwise it is no longer fun but just work. And when it is 
just work then...

Regards, 
-- 
JID:      hrw at jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz