From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: reverting some csets that kill package upgrade paths
Date: Fri, 24 Apr 2009 19:32:57 +0200 [thread overview]
Message-ID: <gsst4a$cvj$1@ger.gmane.org> (raw)
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
next reply other threads:[~2009-04-24 17:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 17:32 Koen Kooi [this message]
2009-04-24 17:55 ` reverting some csets that kill package upgrade paths Philip Balister
2009-04-24 19:03 ` Koen Kooi
2009-04-24 19:14 ` Tom Rini
2009-04-24 19:24 ` Tom Rini
2009-04-24 19:47 ` Koen Kooi
2009-04-24 19:39 ` Koen Kooi
2009-04-24 19:32 ` Tom Rini
2009-04-24 19:48 ` Koen Kooi
2009-04-24 19:53 ` Koen Kooi
2009-04-25 20:40 ` Marcin Juszkiewicz
2009-04-24 20:40 ` Philip Balister
2009-04-27 3:22 ` Tom Rini
2009-04-25 21:18 ` Marcin Juszkiewicz
2009-04-25 21:37 ` Koen Kooi
2009-04-25 21:56 ` Marcin Juszkiewicz
2009-04-26 1:59 ` Carsten Haitzler
2009-04-26 9:27 ` Koen Kooi
2009-04-27 8:46 ` Marcin Juszkiewicz
2009-04-26 1:53 ` Carsten Haitzler
-- strict thread matches above, loose matches on Subject: below --
2009-04-24 17:23 Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='gsst4a$cvj$1@ger.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.