FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-11-2011, 03:38 PM
"Paweł Hajdan, Jr."
 
Default libpng-1.5 smooth upgrade

I'm not a member of QA team or libpng maintainer, but hopefully I'm not
going to write something horribly wrong here.

To ensure good upgrade experience for our users, and learning some
lessons from previous, um... "disruptive" upgrade (1.2 -> 1.4), I'd have
some questions:

1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded?

2) If the upgrade is non-trivial, i.e. just emerge -uDNa world and
revdep-rebuild isn't going to fix it, will we have an upgrade guide,
possibly as a news item?

3) Can we do something to make catching libpng problems easier? As
Samuli pointed out in https://bugs.gentoo.org/show_bug.cgi?id=354479
there is a predictable compilation warning. How about making portage
print it as a QA warning, so more people can report the issues without
even emerging libpng-1.5 on their systems? That may be a good backup
option for the tinderbox too.

4) What have we learned from libpng 1.2 -> 1.4 upgrade? I'd just like to
be better informed.

Finally, it seems that hard work on --as-needed and automatic fixing of
.la files is going to make the upgrade experience better now, right?

Paweł Hajdan, Jr.

P.S. The 1.2 -> 1.4 upgrade wasn't really bad for me, but I guess it
could be frustrating for some people, and I just wonder if we can make
it better.
 
Old 02-11-2011, 03:49 PM
Samuli Suominen
 
Default libpng-1.5 smooth upgrade

On 02/11/2011 06:38 PM, "Paweł Hajdan, Jr." wrote:
> I'm not a member of QA team or libpng maintainer, but hopefully I'm not
> going to write something horribly wrong here.
>
> To ensure good upgrade experience for our users, and learning some
> lessons from previous, um... "disruptive" upgrade (1.2 -> 1.4), I'd have
> some questions:
>
> 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded?

Absolutely.

> 4) What have we learned from libpng 1.2 -> 1.4 upgrade? I'd just like to
> be better informed.

One way under consideration:

We have been discussing about removing libpng.pc, libpng.so and
unversioned headers from the libpng 1.5.x package allowing it to install
parallel with libpng 1.4.x.

That means every package that has been checked working against 1.5.x,
will need to be patched to link against -lpng15, use headers from the
libpng15/ directory and use libpng15.pc instead.


Or we go with the old route as with 1.2 to 1.4 but that means everything
must be ported before it gets KEYWORDS.

> Finally, it seems that hard work on --as-needed and automatic fixing of
> .la files is going to make the upgrade experience better now, right?

Indeed. That's a blessing
 
Old 02-11-2011, 04:13 PM
Michael Haubenwallner
 
Default libpng-1.5 smooth upgrade

On 02/11/2011 05:38 PM, "Paweł Hajdan, Jr." wrote:
> To ensure good upgrade experience for our users, and learning some
> lessons from previous, um... "disruptive" upgrade (1.2 -> 1.4), I'd have
> some questions:

FWIW: For that upgrade I've not used lafile-fixer or anything like that
on my stable x86 binhost.
Instead, alternating 'emerge -uDN world' with 'revdep-rebuild' a couple
of times until there was nothing more to do did work as well.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 02-11-2011, 04:26 PM
Diego Elio Pettenò
 
Default libpng-1.5 smooth upgrade

Il giorno ven, 11/02/2011 alle 17.38 +0100, "Paweł Hajdan, Jr." ha
scritto:
> 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded?

Absolutely.

> 2) If the upgrade is non-trivial, i.e. just emerge -uDNa world and
> revdep-rebuild isn't going to fix it, will we have an upgrade guide,
> possibly as a news item?

As Samuli said we're planning on making it as "standard" as possible,
similarly to what's done with Berkeley DB. This is going to take a bit
more work than a standard bump but will avoid further breakage.

Slotted installation is the thing that makes most sense, especially
since upstream helps us there already by versioning the symbols.

> 3) Can we do something to make catching libpng problems easier? As
> Samuli pointed out in https://bugs.gentoo.org/show_bug.cgi?id=354479
> there is a predictable compilation warning. How about making portage
> print it as a QA warning, so more people can report the issues without
> even emerging libpng-1.5 on their systems? That may be a good backup
> option for the tinderbox too.

Tinderbox is also going to report all those warnings to me, which means
I'll open them to the bugzilla. While it might not cover 100% use cases,
I doubt adding the warning to Portage's "reported" ones is going to
help, based on the experience of not even being able to get
fortify-sources "will overflow" warnings to be acted upon.

> Finally, it seems that hard work on --as-needed and automatic fixing of
> .la files is going to make the upgrade experience better now, right?

Most definitely, yes. It could have been better, to be honest, but it's
definitely not going to be the many-tiers failure we have seen before.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 02-11-2011, 06:51 PM
Alexis Ballier
 
Default libpng-1.5 smooth upgrade

On Friday, February 11, 2011 01:49:43 PM Samuli Suominen wrote:
> > 4) What have we learned from libpng 1.2 -> 1.4 upgrade? I'd just like to
> > be better informed.
>
> One way under consideration:
>
> We have been discussing about removing libpng.pc, libpng.so and
> unversioned headers from the libpng 1.5.x package allowing it to install
> parallel with libpng 1.4.x.
>
> That means every package that has been checked working against 1.5.x,
> will need to be patched to link against -lpng15, use headers from the
> libpng15/ directory and use libpng15.pc instead.

you are seriously considering patching every single package using libpng like
this instead of fixing those that fail??? (and i'm not talking about the fact
that these patches cannot be upstreamed...)

if you want to slot it, better provide something like an eselect module for
libpng.pc/.so

A.
 
Old 02-11-2011, 07:07 PM
Diego Elio Pettenò
 
Default libpng-1.5 smooth upgrade

Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto:
>
> you are seriously considering patching every single package using
> libpng like
> this instead of fixing those that fail??? (and i'm not talking about
> the fact
> that these patches cannot be upstreamed...)

Why not? We're *not* inventing the libpng15 thing at all...

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 02-11-2011, 07:39 PM
Matt Turner
 
Default libpng-1.5 smooth upgrade

On Fri, Feb 11, 2011 at 8:07 PM, Diego Elio Petten <flameeyes@gmail.com> wrote:
> Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto:
>>
>> you are seriously considering patching every single package using
>> libpng like
>> this instead of fixing those that fail??? (and i'm not talking about
>> the fact
>> that these patches cannot be upstreamed...)
>
> Why not? We're *not* inventing the libpng15 thing at all...

I was thinking there's no way this can be a good plan, but if a bunch
packages have to be patched, we might as well slot libpng.

I'm a little unclear about -lpng vs -lpng15. ssuominen tells me on IRC
that probably 90% of packages linking with libpng will fail with 1.5.
These 90% will link with -lpng until a version that supports 1.5 is
released? The remaining 10% will go ahead and link with -lpng15? What
happens when 1.6 is released and breaks compatibility again?

Matt
 

Thread Tools




All times are GMT. The time now is 09:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org