reverting some csets that kill package upgrade paths

reverting some csets that kill package upgrade paths

[Koen Kooi]

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

Re: reverting some csets that kill package upgrade paths

[Philip Balister]

[-- 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 --]

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 24-04-09 19:55, Philip Balister wrote:
> 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.

You're are saying that breaking upgrade paths in .dev with prior notice 
is OK? Shall I go head and delete package_{ipk,deb,rpm}.bbclass then, 
since .dev will only work with package_tar.bbclass?

Upgrade paths are the foundation of package management, breaking them is 
stabbing people using your binaries in the eye. Do you want to tell the 
companies evaluating OE using .dev that they can't use the feature 
anymore that drew them to OE, namely package management?

If it's OK to break package management is it OK to break toolchains as 
well? If people can't use the resulting binaries it should be OK to 
break the compiler that would build them, right?

Without upgrade paths OE is just buildroot with a really slow parser on top.

 > After all .stable exists to provide a sane base for supplying 
packages to users.

Having a stable branch does not mean that turning .dev into an unusable 
wasteland is OK. I was hoping that the focus on quality for the stable 
branch would have a positive impact on .dev, but that doesn't seem to be 
the case.

regards,

Koen

Re: reverting some csets that kill package upgrade paths

[Tom Rini]

On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
> On 24-04-09 19:55, Philip Balister wrote:
>> 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.
>
> You're are saying that breaking upgrade paths in .dev with prior notice  
> is OK? Shall I go head and delete package_{ipk,deb,rpm}.bbclass then,  
> since .dev will only work with package_tar.bbclass?
>
> Upgrade paths are the foundation of package management, breaking them is  
> stabbing people using your binaries in the eye. Do you want to tell the  
> companies evaluating OE using .dev that they can't use the feature  
> anymore that drew them to OE, namely package management?
>
> If it's OK to break package management is it OK to break toolchains as  
> well? If people can't use the resulting binaries it should be OK to  
> break the compiler that would build them, right?
>
> Without upgrade paths OE is just buildroot with a really slow parser on top.

So it's not OK to say "Upstream changed things, and we're following suit
here in the development line.  Over in the stable line we're adding the
extra overhead to allow for a clean upgrade path".

-- 
Tom Rini

Re: reverting some csets that kill package upgrade paths

[Tom Rini]

On Fri, Apr 24, 2009 at 12:14:13PM -0700, Tom Rini wrote:
> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
[snip]
> > Upgrade paths are the foundation of package management, breaking them is  
> > stabbing people using your binaries in the eye. Do you want to tell the  
> > companies evaluating OE using .dev that they can't use the feature  
> > anymore that drew them to OE, namely package management?
> >
> > If it's OK to break package management is it OK to break toolchains as  
> > well? If people can't use the resulting binaries it should be OK to  
> > break the compiler that would build them, right?
> >
> > Without upgrade paths OE is just buildroot with a really slow parser on top.
> 
> So it's not OK to say "Upstream changed things, and we're following suit
> here in the development line.  Over in the stable line we're adding the
> extra overhead to allow for a clean upgrade path".

To be clear going from stable/2009 to stable/2011 should work iff via
stable/2010.  And in stable/2011 we shouldn't have RCONFLICT/RPROVIDES
libwhatever-rename-happend-in-2009.  But I don't think updating dev on a
live system from a few months ago to a few months in the future has to
absolutely work with no human intervention.  It sounds like some apps
need to be rebuilt vs the new libraries or so and that's the problem.

-- 
Tom Rini

Re: reverting some csets that kill package upgrade paths

[Tom Rini]

On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:

> Upgrade paths are the foundation of package management, breaking them is  
> stabbing people using your binaries in the eye. Do you want to tell the  
> companies evaluating OE using .dev that they can't use the feature  
> anymore that drew them to OE, namely package management?

Red Herring.  No commerical device is going to point to some random feed
and just hope things work out fine.  No, they're going to point at their
supported feeds with updates they've tested and fixed any bugs that they
happened to have found (and pushed back because they're Good Guys).

-- 
Tom Rini

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 24-04-09 21:14, Tom Rini wrote:
> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
>> On 24-04-09 19:55, Philip Balister wrote:
>>> 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.
>>
>> You're are saying that breaking upgrade paths in .dev with prior notice
>> is OK? Shall I go head and delete package_{ipk,deb,rpm}.bbclass then,
>> since .dev will only work with package_tar.bbclass?
>>
>> Upgrade paths are the foundation of package management, breaking them is
>> stabbing people using your binaries in the eye. Do you want to tell the
>> companies evaluating OE using .dev that they can't use the feature
>> anymore that drew them to OE, namely package management?
>>
>> If it's OK to break package management is it OK to break toolchains as
>> well? If people can't use the resulting binaries it should be OK to
>> break the compiler that would build them, right?
>>
>> Without upgrade paths OE is just buildroot with a really slow parser on top.
>
> So it's not OK to say "Upstream changed things, and we're following suit
> here in the development line.  Over in the stable line we're adding the
> extra overhead to allow for a clean upgrade path".

The situation is:

1) upstream changed things
2) OE bumped SRCREV to include that
3) upgrade paths existed and were working, no change needed
4) a single packaging issue with ecore made things break, which was 
fixed with 
http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=1496aea759adb716453d0fbf85795a5a6e914484

So far so good, runtime users only get a bit more diskspace used when 
upgrading, old packages can be removed safely by checking for orphaned 
packages.

So the upstream change only wasted a tiny bit of space (less than 10 
megabyte uncompressed), and broke ecore packaging, which got fixed.

After today, with these 3 commits:

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

upgrade paths are broken. It does not break by fixing the packagenames 
to match their old names, it breaks them by messing around with the new 
name. So those 3 commits aren't even a fix!

Repeat after me: the upstream change was already handled in OE while 
keeping upgrade paths.

Again: the upstream change was already handled in OE while keeping 
upgrade paths.

So your statement: "Upstream changed things, and we're following suit 
here in the development line.  Over in the stable line we're adding the 
extra overhead to allow for a clean upgrade path" is misleading since 
there is no extra overhead. Everything was working fine till today. Both 
an opkg upgrade and a build from scratch yielded working results, they 
don't do now.

To re-iterate: the upstream change was already handled in OE while 
keeping upgrade paths.

Now lets assume that in the future we want to break upgrade paths in 
.dev, so we discuss it on the mailinglist and people agree that the 
benefits would outweigh the detriments. And for some reason that change 
isn't accepted in .stable. There will be no overhead to add to .stable, 
since is there was overhead to be added, we would have done it in .dev. 
And if for some weird reason there is some overhead that would fix it 
then the people approving of the breakage in .dev deserve to get smacked 
with a cluebat. Breaking upgrade paths is breaking the foundation of 
package management.

I know that some distro has solved it in the past by completely removing 
all packagefeeds and repopulate them using a build from scratch and told 
users to reflash their device if they wanted to get new bugfixes. And I 
also know that adding PE = "1" to a single bbclass would have fixed 
those upgrade paths for that distro and its users without needing to 
clean out the feeds or reflash each and every device.
This sort of fuckups should be handled where they were introduced, which 
in this case is in OE, not upstream.

regards,

Koen

PS: I don't support the soname change the e folks did, but it was rather 
benign, only a single recipe needed changes to FILES.

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 24-04-09 21:24, Tom Rini wrote:
>  But I don't think updating dev on a
> live system from a few months ago to a few months in the future has to
> absolutely work with no human intervention.

I don't think that either, but those 3 csets from today don't fix 
anything, they just introduce breakage. the 'problem' they try to 
address (soname change) is a non-problem from a package manager POV, the 
only breakage with ecore not packaging files had been fixed already.

Sometimes there are good reasons to rename packages, and OE can't have 
some cases with RPROVIDES, since debian.bbclass is too helpfull in some 
cases, e.g:

package (not recipe!) foo renamed to libfoo (e.g by inheriting 
lib_package). You add RPROVIDES_libfoo = "foo" -> debian.bbclass turns 
that into: Provides: libfoo

But this revert request is not about that, it's about reverting breakage 
that serves no use.

regards,

Koen

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 24-04-09 21:32, Tom Rini wrote:
> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
>
>> Upgrade paths are the foundation of package management, breaking them is
>> stabbing people using your binaries in the eye. Do you want to tell the
>> companies evaluating OE using .dev that they can't use the feature
>> anymore that drew them to OE, namely package management?
>
> Red Herring.  No commerical device is going to point to some random feed
> and just hope things work out fine.  No, they're going to point at their
> supported feeds with updates they've tested and fixed any bugs that they
> happened to have found (and pushed back because they're Good Guys).
>

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 24-04-09 21:32, Tom Rini wrote:
> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
>
>> Upgrade paths are the foundation of package management, breaking them is
>> stabbing people using your binaries in the eye. Do you want to tell the
>> companies evaluating OE using .dev that they can't use the feature
>> anymore that drew them to OE, namely package management?
>
> Red Herring.  No commerical device is going to point to some random feed
> and just hope things work out fine.  No, they're going to point at their
> supported feeds with updates they've tested and fixed any bugs that they
> happened to have found (and pushed back because they're Good Guys).

My point is that OE won't make it 'into' the commercial device since the 
evaluating came out negative.
BTW, I've already seen a company messing up the feeds for their 
commercial device by broken upgrade paths.

regards,

Koen

And why is the spellcheck button next to the send button in thunderbird? 
I've already sent 3 bogus mails today because my motoric skills suffer 
from a lack of coffee

Re: reverting some csets that kill package upgrade paths

[Philip Balister]

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

Tom Rini wrote:
> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
> 
>> Upgrade paths are the foundation of package management, breaking them is  
>> stabbing people using your binaries in the eye. Do you want to tell the  
>> companies evaluating OE using .dev that they can't use the feature  
>> anymore that drew them to OE, namely package management?
> 
> Red Herring.  No commerical device is going to point to some random feed
> and just hope things work out fine.  No, they're going to point at their
> supported feeds with updates they've tested and fixed any bugs that they
> happened to have found (and pushed back because they're Good Guys).

I disagree. Angstrom is usable and depends on stable having sane upgrade 
paths as a community supported distro.

The issue here is under what circumstances is breaking upgrade paths in 
dev acceptable.

Certainly, we do not want to make more work than needed for people 
basing distributions from OE, whether they are commercial or community 
based.

Philip

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

Re: reverting some csets that kill package upgrade paths

[Marcin Juszkiewicz]

Dnia piątek, 24 kwietnia 2009 o 21:53:33 Koen Kooi napisał(a):
> And why is the spellcheck button next to the send button in
> thunderbird? I've already sent 3 bogus mails today because my motoric
> skills suffer from a lack of coffee

RMB on toolbar and you can edit that toolbar to have them on different 
sides of toolbar...

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

Re: 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@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 25-04-09 23:18, Marcin Juszkiewicz wrote:

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

Well, I verified that e-wm started in beagleboard-demo-image in a build 
from scratch and in an upgraded images 2 days ago, so any problems those 
3 patches were supposed to fix weren't that critical.
*After* those 3 patches I have a broken build and broken upgrade paths, 
while *before* things were working for me.

I actually tested the changes I made for build from scratch as well as 
upgrading an image. While upgrading I actually noticed the ecore bug 
which was present. I could have revert the SRCREV bump, but I went ahead 
and fixed it. So you can see why I get annoyed that a few days later it 
gets broken again by the same person.

regards,

Koen

Re: reverting some csets that kill package upgrade paths

[Marcin Juszkiewicz]

Dnia sobota, 25 kwietnia 2009 o 23:37:14 Koen Kooi napisał(a):
> On 25-04-09 23:18, Marcin Juszkiewicz wrote:

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

> > Provide a patch which will add such ones?

> Well, I verified that e-wm started in beagleboard-demo-image in a
> build from scratch and in an upgraded images 2 days ago, so any
> problems those 3 patches were supposed to fix weren't that critical.
> *After* those 3 patches I have a broken build and broken upgrade
> paths, while *before* things were working for me.

> I actually tested the changes I made for build from scratch as well
> as upgrading an image. While upgrading I actually noticed the ecore
> bug which was present. I could have revert the SRCREV bump, but I
> went ahead and fixed it. 

But origin/org.openembedded.dev is not koen/org.openembedded.dev - you 
are *not the only user* of that branch (asterisks added because it looks 
like you like them). And we have a weekend now - you should wait and 
check what would other say about those 3 changsets. As I said: 
origin/org.openembedded.dev is not your sandbox - we also like to play 
there.

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

Re: reverting some csets that kill package upgrade paths

[Carsten Haitzler]

On Fri, 24 Apr 2009 19:32:57 +0200 Koen Kooi <k.kooi@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.

> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com

Re: reverting some csets that kill package upgrade paths

[Carsten Haitzler]

On Sat, 25 Apr 2009 23:56:17 +0200 Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> said:

> Dnia sobota, 25 kwietnia 2009 o 23:37:14 Koen Kooi napisał(a):
> > On 25-04-09 23:18, Marcin Juszkiewicz wrote:
> 
> > >> 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*.
> 
> > > Provide a patch which will add such ones?
> 
> > Well, I verified that e-wm started in beagleboard-demo-image in a
> > build from scratch and in an upgraded images 2 days ago, so any
> > problems those 3 patches were supposed to fix weren't that critical.
> > *After* those 3 patches I have a broken build and broken upgrade
> > paths, while *before* things were working for me.
> 
> > I actually tested the changes I made for build from scratch as well
> > as upgrading an image. While upgrading I actually noticed the ecore
> > bug which was present. I could have revert the SRCREV bump, but I
> > went ahead and fixed it. 
> 
> But origin/org.openembedded.dev is not koen/org.openembedded.dev - you 
> are *not the only user* of that branch (asterisks added because it looks 
> like you like them). And we have a weekend now - you should wait and 
> check what would other say about those 3 changsets. As I said: 
> origin/org.openembedded.dev is not your sandbox - we also like to play 
> there.

true - not the onyl user.. but if it breaks for him.. that is a break - and
something to fix. if changes broke something - fix the changes or revert. i
guess this thread is about screaming "revert!" in  hopes that the changes will
get fixed asap before a revert actually happens (and you start some
commit/revert war) :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com

Re: reverting some csets that kill package upgrade paths

[Koen Kooi]

On 25-04-09 23:18, Marcin Juszkiewicz wrote:

>> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=
>> 8101ad8e1229b3b9f8aa0be0fdc262b5283034d0
>
> This one looks quite sane.

Maybe if you use debian.bbclass, if you don't -> broken upgrade paths

regards,

Koen

Re: reverting some csets that kill package upgrade paths

[Tom Rini]

On Fri, Apr 24, 2009 at 04:40:42PM -0400, Philip Balister wrote:
> Tom Rini wrote:
>> On Fri, Apr 24, 2009 at 09:03:18PM +0200, Koen Kooi wrote:
>>
>>> Upgrade paths are the foundation of package management, breaking them 
>>> is  stabbing people using your binaries in the eye. Do you want to 
>>> tell the  companies evaluating OE using .dev that they can't use the 
>>> feature  anymore that drew them to OE, namely package management?
>>
>> Red Herring.  No commerical device is going to point to some random feed
>> and just hope things work out fine.  No, they're going to point at their
>> supported feeds with updates they've tested and fixed any bugs that they
>> happened to have found (and pushed back because they're Good Guys).
>
> I disagree. Angstrom is usable and depends on stable having sane upgrade  
> paths as a community supported distro.

The key being stable.  If I wasn't clear, a feed based on .dev is most
certainly random.  A feed for a specific release would hopefully not be
based on .dev.  A company working with Angstrom is feasible and would be
what I said :)

-- 
Tom Rini

Re: reverting some csets that kill package upgrade paths

[Marcin Juszkiewicz]

Dnia niedziela, 26 kwietnia 2009 o 11:27:36 Koen Kooi napisał(a):
> On 25-04-09 23:18, Marcin Juszkiewicz wrote:
> >> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=
> >> 8101ad8e1229b3b9f8aa0be0fdc262b5283034d0
> >
> > This one looks quite sane.
>
> Maybe if you use debian.bbclass, if you don't -> broken upgrade paths

Ah, right - I am too used to debian.bbclass being in use...

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

reverting some csets that kill package upgrade paths

[Koen Kooi]

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.