[oe] [OE-core] [oe-commits] Andrei Dinu : libffi upgrade to 3.0.11

[Martin Jansa]

On Sat, Sep 15, 2012 at 09:39:32PM +0100, Phil Blundell wrote:
> On Sat, 2012-09-15 at 19:28 +0200, Martin Jansa wrote:
> > On Sat, Sep 15, 2012 at 06:23:37PM +0100, Phil Blundell wrote:
> > > On Sat, 2012-09-15 at 18:20 +0200, Martin Jansa wrote:
> > > > This changes .so name from libffi5 to libffi6, breaking every recipe
> > > > depending on libffi when someone is using debian.bbclass.
> > > 
> > > How exactly do the recipes break?  The whole point of debian.bbclass is
> > > to avoid breakage when this happens by making libffi5 and libffi6
> > > parallel installable.  If that isn't working then there is clearly a bug
> > > somewhere and we should fix that.
> > 
> > libffi5 is no longer in feed, so if you try to install something from
> > feed which still has libffi5 in depends it will fail.
> 
> Ah, right.  So it's not actually the recipes which are broken, it's just
> that something is wrong with whatever maintains the feed and the old
> binaries are no longer installable.  I guess you need to figure out why
> libffi5 is being removed and prevent that from happening.

Old ipk binaries are removed in package_write_ipk task.

Even when I keep those binaries in public feed (rsynced from
deploy/ipk/) then I would have to call opkg-make-index in that public
feed to keep them in Packages too.

So by default you can assume that libffi5*.ipk gets missing as soon as you
bump libffi to version with new .so name like libffi6.

And it's not only someone doing opkg install on target, do_rootfs fails
too if you have any of those affected packages in your image.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20120916/c4593d5a/attachment-0002.sig>