[oe] reverting some csets that kill package upgrade paths
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Sun Apr 26 03:53:00 CEST 2009
On Fri, 24 Apr 2009 19:32:57 +0200 Koen Kooi <k.kooi at student.utwente.nl> said:
here's my take - koen's original change was pretty much good - it just adapted
to the naming scheme packaging the right stuff in the right place. linbker and
ld.so seem to happily cope with the naming scheme and for us it means less
"breakage" as we have very explicit namings of .so's between snapshots - on oe
and purely package managed distros this doesn't matter that much but for a lot
of people who compile AND install from source (from tarballs or svn) it will
mean much more stability as things link with what they were meant to link with
and not "whatever is there at the time".
this is meant to bring more stability during development as we break api's and
so on. a simple adapting to it with FILES_* = ... stuff works just fine and
probably is a good way to go.
> 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:
> So after that cset you'd get a completely working rootfs again with e17
> Today a few csets have been pushed that break things horribly:
> 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.
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the Openembedded-devel