[gentoo-dev] libpng-1.5 smooth upgrade

[gentoo-dev] libpng-1.5 smooth upgrade

["Paweł Hajdan, Jr."]

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

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Samuli Suominen]

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 :)

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Alexis Ballier]

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.

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Diego Elio Pettenò]

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/

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Matt Turner]

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

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Duncan]

Matt Turner posted on Fri, 11 Feb 2011 20:39:04 +0000 as excerpted:

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

That last is my first thought as well.

If we go ahead and patch a whole bunch of stuff to -lpng15, we're locking 
ourselves in to screwing with them for 1.6 and beyond, as well.  It seems 
to me that if we're going to patch, patch the real problem, so -lpng 
continues to work, and then we'll only be forced to fix what breaks with 
1.6 when it comes out, not everything we broke by locking it to 1.5 
specifically, as well.

But I'm not the one doing the patching, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Alexis Ballier]

On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò 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...

as i read it, it's breaking the libpng.so/pc thing however...

A.

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 642 bytes --]

On Friday, February 11, 2011 18:33:32 Alexis Ballier wrote:
> On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò 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...
> 
> as i read it, it's breaking the libpng.so/pc thing however...

so why dont you ask the libpng upstream people ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Alexis Ballier]

On Friday, February 11, 2011 08:44:04 PM Mike Frysinger wrote:
> On Friday, February 11, 2011 18:33:32 Alexis Ballier wrote:
> > On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò 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...
> > 
> > as i read it, it's breaking the libpng.so/pc thing however...
> 
> so why dont you ask the libpng upstream people ?

ask what ?
"pretty please dont install libpng.pc/.so, pretty please force every consumer 
to hardcode the version because i know people that want to do this" ?

Thanks, I'm fine with having it non slotted.

A.

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Enrico Weigelt]

* Alexis Ballier <aballier@gentoo.org> schrieb:

> > so why dont you ask the libpng upstream people ?
> 
> ask what ?
> "pretty please dont install libpng.pc/.so, 

Exactly that.

And it's exactly what I'm going to fix in OSS-QM when I'm adding
libpng-1.5 in a few days.

> pretty please force every consumer to hardcode the version
> because i know people that want to do this" ?

No, they should use pkg-config at buildtime and do the version
selection there (eg. the eselect-way).

> Thanks, I'm fine with having it non slotted.

And ending up with largely broken systems once again (and again,
and again, with coming releases) ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Samuli Suominen]

On 02/24/2011 05:26 PM, Enrico Weigelt wrote:
> And it's exactly what I'm going to fix in OSS-QM when I'm adding
> libpng-1.5 in a few days.

not this oss-qm again... not sure how to put "nobody cares" politely

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Enrico Weigelt]

* Enrico Weigelt <weigelt@metux.de> schrieb:

> > pretty please force every consumer to hardcode the version
> > because i know people that want to do this" ?
> 
> No, they should use pkg-config at buildtime and do the version
> selection there (eg. the eselect-way).

Oh, it gets a bit tricker: the dependencies of the installed
packages will have to be fixed to the actually used version/slot.

hmm, maybe this also could be done via some eclass, that adds
an useflag for libpng version selection ?

I could imagine a way like that:

* libpng15 is installed in a way that it doesnt conflict with existing
  libpng14 (different locations, pkg-config name, slotted, etc)
* pass pkg-config calls through a wrapper that automatically
  chooses the right .pc file on some environment variable etc.
* each libpng-using package that should be buildable against libpng15
  is changed to use the new eclass (that does all the switching magic)

IMHO this should allow keeping the (runtime) dependencies intact
(no revdep-rebuild required) and allow an smooth upgrade. When
everything had been rebuilt against libpng15 one day, --depclean
would kick off old libpng14.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Rémi Cardona]

Le 26/02/2011 17:08, Enrico Weigelt a écrit :
> I could imagine a way like that:
[...]

Or we can do it like distributions always do (at least we do) :

1) find packages that don't work out of the box with libpng 1.5
2) work with upstream to fix them

Really, libpng15 is to libpng14 what gtk3 is to gtk2: a new library.
Let's treat it as such.

Rémi

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1363 bytes --]

On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote:
> On 02/11/2011 06:38 PM, "Paweł Hajdan, Jr." 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.
> 
> 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.

i dont see any real advantages with SLOT-ed installs of libpng beyond ABI 
(i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x).  there are 
however plenty of downsides.  patching packages in the tree is a huge hassle, 
you add hassle to end users who d/l random packages and try to build things 
themselves, and you make Gentoo non-standard wrt every other distro out there.

best we follow what everyone else is already doing, and what upstream packages 
will have to ultimately do anyways -- fix their code to work with libpng-1.5 
when the API has been forcibly broken.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Nikos Chantziaras]

On 02/13/2011 01:21 AM, Mike Frysinger wrote:
> On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote:
>> On 02/11/2011 06:38 PM, "Paweł Hajdan, Jr." wrote:
>>> 4) What have we learned from libpng 1.2 ->  1.4 upgrade? I'd just like to
>>> be better informed.
>>  [...]
>> 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.
>>  [...]
>
> i dont see any real advantages with SLOT-ed installs of libpng beyond ABI
> (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x).  there are
> however plenty of downsides.  patching packages in the tree is a huge hassle,
> you add hassle to end users who d/l random packages and try to build things
> themselves, and you make Gentoo non-standard wrt every other distro out there.
>
> best we follow what everyone else is already doing, and what upstream packages
> will have to ultimately do anyways -- fix their code to work with libpng-1.5
> when the API has been forcibly broken.

Or you can mask libpng-1.5 since most users aren't interested in having 
the latest version of something they won't be using directly.  Wait 
until packages have been fixed upstream.  Then 8 months or a year later, 
unmask it.

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1445 bytes --]

On Saturday, February 12, 2011 18:31:12 Nikos Chantziaras wrote:
> On 02/13/2011 01:21 AM, Mike Frysinger wrote:
> > On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote:
> >> On 02/11/2011 06:38 PM, "Paweł Hajdan, Jr." wrote:
> >>> 4) What have we learned from libpng 1.2 ->  1.4 upgrade? I'd just like
> >>> to be better informed.
> >> 
> >> 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.
> > 
> > i dont see any real advantages with SLOT-ed installs of libpng beyond ABI
> > (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x).  there
> > are however plenty of downsides.  patching packages in the tree is a
> > huge hassle, you add hassle to end users who d/l random packages and try
> > to build things themselves, and you make Gentoo non-standard wrt every
> > other distro out there.
> > 
> > best we follow what everyone else is already doing, and what upstream
> > packages will have to ultimately do anyways -- fix their code to work
> > with libpng-1.5 when the API has been forcibly broken.
> 
> Or you can mask libpng-1.5 since most users aren't interested in having
> the latest version of something they won't be using directly.  Wait
> until packages have been fixed upstream.  Then 8 months or a year later,
> unmask it.

that isnt how we work
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Diego Elio Pettenò]

Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto:
> patching packages in the tree is a huge hassle, 
> you add hassle to end users who d/l random packages and try to build
> things 
> themselves, and you make Gentoo non-standard wrt every other distro
> out there. 

What I had in mind was something that would work for upstreams as well,
mostly by having fallback; so if a package supported up to libpng 1.4 it
would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
-lpng12 -lpng ...

i.e. what most already do for berkdb but at some point with us not
providing -lpng at all, if most upstreams would like that idea.

But it's still a bit hairy at the moment, I admit it might just not fly.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1541 bytes --]

On Saturday, February 12, 2011 21:37:29 Diego Elio Pettenò wrote:
> Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto:
> > patching packages in the tree is a huge hassle,
> > you add hassle to end users who d/l random packages and try to build
> > things
> > themselves, and you make Gentoo non-standard wrt every other distro
> > out there.
> 
> What I had in mind was something that would work for upstreams as well,
> mostly by having fallback; so if a package supported up to libpng 1.4 it
> would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
> hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
> -lpng12 -lpng ...
> 
> i.e. what most already do for berkdb but at some point with us not
> providing -lpng at all, if most upstreams would like that idea.

i'm not sure comparing to berkdb is appropriate.  upstream packages using 
berkdb have themselves changed to doing a version scan before falling back to 
the canonical one.  if upstream packages start changing to do that with 
libpng, then perhaps we can talk about restructuring libpng ebuilds, but it 
seems to me that upstream packages are more likely to simply update their code 
to work with libpng-1.5 than add a version scan for libpng-1.4.

thus it's a lot more sane in the long term to assume that packages support the 
latest rather than patching everyone (and being forced to carry those custom 
patches indefinitely) to set the ceiling at the last "known" working version.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: Re: libpng-1.5 smooth upgrade

[Diego Elio Pettenò]

Il giorno dom, 13/02/2011 alle 14.22 -0500, Mike Frysinger ha scritto:
> 
> thus it's a lot more sane in the long term to assume that packages
> support the 
> latest rather than patching everyone (and being forced to carry those
> custom 
> patches indefinitely) to set the ceiling at the last "known" working
> version. 

Okay so what would you think of installing the headers and .pc files for
the "previous ABI" slotted packages? It would extend a bit more the
non-latest, but wouldn't stray far from what we've done up to now, and
we'd have a proof of concept to show upstream how to implements the
fallbacks... then we could probably talk some of them to do just that.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 866 bytes --]

On Sunday, February 13, 2011 15:16:58 Diego Elio Pettenò wrote:
> Il giorno dom, 13/02/2011 alle 14.22 -0500, Mike Frysinger ha scritto:
> > thus it's a lot more sane in the long term to assume that packages
> > support the latest rather than patching everyone (and being forced to
> > carry those custom patches indefinitely) to set the ceiling at the last
> > "known" working version.
> 
> Okay so what would you think of installing the headers and .pc files for
> the "previous ABI" slotted packages? It would extend a bit more the
> non-latest, but wouldn't stray far from what we've done up to now, and
> we'd have a proof of concept to show upstream how to implements the
> fallbacks... then we could probably talk some of them to do just that.

i'm not sure how this is really any different from an arbitrary number of 
parallel slots.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Alexis Ballier]

On Saturday, February 12, 2011 11:37:29 PM Diego Elio Pettenò wrote:
> Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto:
> > patching packages in the tree is a huge hassle,
> > you add hassle to end users who d/l random packages and try to build
> > things
> > themselves, and you make Gentoo non-standard wrt every other distro
> > out there.
> 
> What I had in mind was something that would work for upstreams as well,
> mostly by having fallback; so if a package supported up to libpng 1.4 it
> would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
> hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
> -lpng12 -lpng ...
> 
> i.e. what most already do for berkdb but at some point with us not
> providing -lpng at all, if most upstreams would like that idea.
> 
> But it's still a bit hairy at the moment, I admit it might just not fly.

I consider the berkdb thingy as an example of something not to do rather than 
a proof of concept.

Have you thought about doing something like what was done for wxwidgets ?

- an eselect module for out of portage builds
- an eclass creating symlinks for libpng.pc/.so in $T and setting the correct 
-L flag for the linker and PKG_CONFIG_PATH for the .pc ?

Not sure if this would work that easily but that's certainly better than 
updating the version scans in every single package when a new libpng comes 
out.

A.

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Mike Frysinger]

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

On Monday, February 14, 2011 10:37:27 Alexis Ballier wrote:
> On Saturday, February 12, 2011 11:37:29 PM Diego Elio Pettenò wrote:
> > Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto:
> > > patching packages in the tree is a huge hassle,
> > > you add hassle to end users who d/l random packages and try to build
> > > things themselves, and you make Gentoo non-standard wrt every other
> > > distro out there.
> > 
> > What I had in mind was something that would work for upstreams as well,
> > mostly by having fallback; so if a package supported up to libpng 1.4 it
> > would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
> > hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
> > -lpng12 -lpng ...
> > 
> > i.e. what most already do for berkdb but at some point with us not
> > providing -lpng at all, if most upstreams would like that idea.
> > 
> > But it's still a bit hairy at the moment, I admit it might just not fly.
> 
> I consider the berkdb thingy as an example of something not to do rather
> than a proof of concept.
> 
> Have you thought about doing something like what was done for wxwidgets ?

i dont think that model is appropriate either.  wxwidgets maintains parallel 
version branches.  libpng does not.

> - an eselect module for out of portage builds

generally if an eselect module is necessary, that says to me that something 
more fundamental is broken.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Ryan Hill]

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

On Mon, 14 Feb 2011 12:37:27 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> Have you thought about doing something like what was done for wxwidgets ?
> 
> - an eselect module for out of portage builds
> - an eclass creating symlinks for libpng.pc/.so in $T and setting the correct 
> -L flag for the linker and PKG_CONFIG_PATH for the .pc ?
> 
> Not sure if this would work that easily but that's certainly better than 
> updating the version scans in every single package when a new libpng comes 
> out.

I wouldn't recommend the wxwidgets method for something like libpng.  The
biggest wart is that every wxwidgets-using package has to use the framework
or things will go haywire.  The only thing that makes it maintainable is the
relatively small number of these packages.

wxwidgets was also designed for parallel installs from the beginning (that's
what they claim anyways, we have to do a fair bit of hacking on it), so it has
a well-established interface for choosing versions that every package already
uses.  We just sort of sit in the middle of that and translate.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

[Enrico Weigelt]

* Diego Elio Pettenò <flameeyes@gmail.com> schrieb:

> What I had in mind was something that would work for upstreams as well,
> mostly by having fallback; so if a package supported up to libpng 1.4 it
> would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
> hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
> -lpng12 -lpng ...

In case of multiple versions are installed, that would make the
dependency tracking unstable - the package management doesn't
know which version had been chosen.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Michael Haubenwallner]

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

[gentoo-dev] Re: libpng-1.5 smooth upgrade

[Diego Elio Pettenò]

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/