media-libs/libpng breaks again (>= 1.4.8-r2 now masked in Funtoo)
Adrien Dessemond
be a some form of good news for any other package, in the case of
libpng it seems to be a source of troubles and the updated 1.4 made no
exception: some statements in the ebuild have been changed without
notice and now makes portage protest it cannot resolve dependencies
(major blocks). It also affects x11-libs/cairo (build failure) which
in turns can affect several packages.
From now on all revisions of media-libs/libpng >= 1.4.8-r2 are masked
in Funtoo until the a stable solution to that problem is found. Our
tree tree is being regenerated to reflect the changes.
If you have a broken libpng, reverting back to the old 1.4.8-r1
version is not complicated: just reemerge media-libs/libpng-1.4.8-r1,
reemerge x11-libs/cairo and do a revdep-rebuild to ensure about the
correctness of who uses what.
Sorry again to not have catched that before :-(
Guy Fontaine
--
To manage your subscription, visit this group at
http://groups.google.com/group/funtoo-dev?hl=en
---
Also be sure to check out:
Funtoo Forums: http://forums.funtoo.org
Planet Larry: http://larrythecow.org
Salutations/Regards,
Guy Fontaine (AKA aramis_qc)
Guy Fontaine
Hi,
its because it is put into a new slot (1.4) while 1.4.8-r1 was in slot
(0).
I put the ebuild into my local overlay and changed the slot of 1.4.8-
r2 from 1.4 to 0 and everthing is going well.
t.l.
Karl
--
To manage your subscription, visit this group at
http://groups.google.com/group/funtoo-dev?hl=en
---
Also be sure to check out:
Funtoo Forums: http://forums.funtoo.org
Planet Larry: http://larrythecow.org
Adrien Dessemond
>
> Cool !
> Did you submit to Gentoo Bugzilla so they fix that issue the fastest and the
> soonest possible ?
In the present case fellows pushed something *without* testing it first.
It is their problem to learn to not push clearly untested stuff
unmasked especially when the stuff in question is a "pillar" package.
If an update would be necessary we will test a later release and see
how things are going before pushing/unmasking it in the Funtoo tree.
Reverting the mistake is pretty easy and the Funtoo flavor of the
package already holds the fix. It is not for nothing if one of our
policies is to mask some updates to not break everything everywhere.
Mike Gilbert
> On Sun, Sep 18, 2011 at 4:23 PM, Guy Fontaine <aram...@gmail.com> wrote:
>
>>
>> Cool !
>> Did you submit to Gentoo Bugzilla so they fix that issue the fastest and the
>> soonest possible ?
>
> In the present case fellows pushed something *without* testing it first.
> It is their problem to learn to not push clearly untested stuff
> unmasked especially when the stuff in question is a "pillar" package.
I just want to point out that in this case, funtoo has its own mask for
libpng-1.5, which is what messed things up. It wasn't lack of testing on
the gentoo side.
In gentoo, Samuli commited libpng-1.4.8-r2 at the same time that
libpng-1.5 was unmasked, so everything worked out.
libpng-1.4 -> slot 1.4
libpng-1.5 -> slot 0
Daniel Robbins
>
> I just want to point out that in this case, funtoo has its own mask for
> libpng-1.5, which is what messed things up. It wasn't lack of testing on
> the gentoo side.
>
> In gentoo, Samuli commited libpng-1.4.8-r2 at the same time that
> libpng-1.5 was unmasked, so everything worked out.
>
> libpng-1.4 -> slot 1.4
> libpng-1.5 -> slot 0
Thanks for the info. Is the general approach to use SLOT 0 for the
current libpng API and then rename it to say, 1.5 if there is API
breakage and push a new slot 0 to represent the new current API?
Does this work? It seems like it might lead "SLOT 0" to potentially
mean multiple things, but I'm not sure if there is a better way.
-Daniel
Mike Gilbert
> Thanks for the info. Is the general approach to use SLOT 0 for the
> current libpng API and then rename it to say, 1.5 if there is API
> breakage and push a new slot 0 to represent the new current API?
>
I believe so. This basically happens every time libpng has a release.
The goal is to always compile things against the newest version of the
libpng API.
libpng:1.2 and libpng:1.4 are there for pre-compiled packages that
cannot simply be recompiled against the new API. These slots install
only the .so file and not the headers or pkgconfig info.
> Does this work? It seems like it might lead "SLOT 0" to potentially
> mean multiple things, but I'm not sure if there is a better way.
It appears to work, but it obviously requires some synchronization.
Adrien Dessemond
> The goal is to always compile things against the newest version of the
> libpng API.
>
> libpng:1.2 and libpng:1.4 are there for pre-compiled packages that
> cannot simply be recompiled against the new API. These slots install
> only the .so file and not the headers or pkgconfig info.
Mike, thanks for the precisions it is clearer but I am still worried:
what would happen in the case of an existing package that needs to be
rebuilt against 1.4 because of 1.5 API incompatibilities? Is 1.4 and
1.5 not being installable side-by-side? Funtoo (and Gentoo) cannot
offer another libpng12 disaster and this is why I had masked 1.5
several weeks ago to prevent such a catastrophe to happen and leave us
a chance to fix the potential issues before seeing Funtoo being badly
broken. However I was not aware of that revision bumping cycle (0 ->
1.4 for 1.4.x series in order to bring in 1.5.x series) at that time
and in my book libpng 1.4 would have been slotted as "0" forever and
1.5 would have lived in its own slot as well forever.
>> Does this work? It seems like it might lead "SLOT 0" to potentially
>> mean multiple things, but I'm not sure if there is a better way.
> It appears to work, but it obviously requires some synchronization.
What to you intend by "synchronization" ? I am sure we will be will
very happy to help Gentoo by the same occasion.
I still have question marks in the eyes.... :-(
Mike Gilbert
> On 09/19/2011 05:13 PM, Mike Gilbert wrote:
>> On 9/19/2011 5:47 PM, Daniel Robbins wrote:
>>> Thanks for the info. Is the general approach to use SLOT 0 for the
>>> current libpng API and then rename it to say, 1.5 if there is API
>>> breakage and push a new slot 0 to represent the new current API?
>>>
>>
>> I believe so. This basically happens every time libpng has a release.
>>
>> The goal is to always compile things against the newest version of the
>> libpng API.
>
> new versions of libpng have an incompatible api?
>
You are certainly not the first person to ask that question. Ask
upstream. :)
Mike Gilbert
> On Mon, Sep 19, 2011 at 6:13 PM, Mike Gilbert <flo...@gentoo.org> wrote:
>
>> The goal is to always compile things against the newest version of the
>> libpng API.
>>
>> libpng:1.2 and libpng:1.4 are there for pre-compiled packages that
>> cannot simply be recompiled against the new API. These slots install
>> only the .so file and not the headers or pkgconfig info.
>
> Mike, thanks for the precisions it is clearer but I am still worried:
> what would happen in the case of an existing package that needs to be
> rebuilt against 1.4 because of 1.5 API incompatibilities?
The approach Gentoo takes is to get all dependent packages working with
libpng-1.5. As you can see from the tracker bug[1], a lot of work has
already gone into this.
> Is 1.4 and 1.5 not being installable side-by-side?
Although this is technically possible, it does mean more work since we
have to test reverse dependencies across multiple versions on different
architectures. As well, you do have to choose 1 as the default for
packages that simply want "libpng".
It seems that Gentoo maintainers of libpng have chosen to throw their
effort into supporting the latest libpng releases over maintaining all
of them.
>> It appears to work, but it obviously requires some synchronization.
>
> What to you intend by "synchronization" ? I am sure we will be will
> very happy to help Gentoo by the same occasion.
If you are going to hard mask libpng releases yourself, I think that you
should also fork the package so you have better control over it. The
alternative is to let the Gentoo maintainer decide when unmasking is
appropriate.
Rob Landley
>> Thanks for the info. Is the general approach to use SLOT 0 for the
>> current libpng API and then rename it to say, 1.5 if there is API
>> breakage and push a new slot 0 to represent the new current API?
>>
>
> I believe so. This basically happens every time libpng has a release.
>
> The goal is to always compile things against the newest version of the
> libpng API.
Has the png file format actually changed in the past 15 years? Why do
new versions of libpng have an incompatible api?
Rob
Daniel Robbins
>
> If you are going to hard mask libpng releases yourself, I think that you
> should also fork the package so you have better control over it. The
> alternative is to let the Gentoo maintainer decide when unmasking is
> appropriate.
I agree with this - we should fork libpng if we are going to keep the mask.
Regards,
Daniel
Oleg
1.5.4, it works, though, we decided to wait untill all possible issues
(if any) solved in gentoo.
@floppym, Is there a good reason to update to libpng-1.5.4?
On 20 сен, 08:20, Daniel Robbins <drobb...@funtoo.org> wrote:
Mike Gilbert
> @floppym, Is there a good reason to update to libpng-1.5.4?
I'm not sure; I don't really follow its development. I just went through
the upgrade so I could test some packages that link against it.