Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Sun Apr 3 07:49:43 UTC 2016

control: severity -1 important

Hi Tanguy, sorry for the late reply

On 02/04/2016 10:41, Tanguy Ortoo wrote:
> Package: libgdk-pixbuf2.0-dev
> Version: 2.32.3-1.2
> Severity: grave
> Justification: renders package unusable
> 

^^ nonsense to me.

if with "unusable" you mean experimental, well, it is there to be broken, and in 
case of transition it usually *is* broken, specially because release team
almost never did a binNMU there.

> While trying to build a new version of my package latexila for
> experimental, I noticed it was failing because of libgtk-pixbuf2.0-dev.
> Indeed, that package, in unstable and in experimental as well:
> 
> * ships a gdk-pixbuf2.0.pc that requires libpng12.pc;
> * depends on libpng-dev which:
>   - on experimental, is a real package that does not ship libpng12.pc
>     but only libpng16.pc and libpng.pc;

this is a known issue, and you should just binNMU gdk-pixbuf (I did an NMU with a special libpng16-dev build dependency,
but with the new libpng1.6 that provides a real libpng-dev and no libpng16-dev a new binNMU has to be performed).

>   - on unstable, is provided by libpng12-dev which does provide
>     libpng12.pc, but that situation should change to that of
>     experimental whenever the new libpng-dev real package is uploaded to
>     it.

that is going to change soon (TM)

> 
> 
> Basically, when requiring libpng12.pc, it does not seem right to depend
> on a package, either virtual or real, that is not guaranteed to provide
> it. In my opinion, in its current state, libgdk-pixbuf2.0-dev should
> depend on libpng12-dev as this is what it uses, and not on libpng-dev
> which may or may not provide what it currently needs.
> 

where? unstable or experimental? you say both unstable and experimental are broken.

experimental is broken by definition of transition, while unstable should be fixed, simple as is.
in experimental libpng-dev is provided by libpng12-dev so the current transition shoulnd't be an issue.

and I don't even see your point.
"unstable is broken, so I want to upload to experimental which is by definition even more broken"

that sound really strange to me.

> 
> Since there is a transition to make to libpng-dev, one solution would be
> to rebuild gdk-pixbuf for experimental, but doing it in an environment
> with libpng12-dev not installed and libpng-dev installed from
> experimental. That way, its configure script (l. 18507) would just pick
> libpng16 and the resulting gdk-pixbuf2.0.pc would require the
> libpng16.pc it provides:
> 

conflicts is a good choice here (I didn't test, but it has never given us troubles building it on experimental with
a forced libpng-dev, because real packages has higer priority than Provides packages, so the png16 toolchain
should be choosen with a simple binNMU)

>> for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do
>>  […]
> 
> 
> In the longer term, it could be better to have the configure script
> check for libpng before libpng16 or libpng12:
> 
>> for l in libpng libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do
>>  […]
> 
> 
> That way, it would not even need to be adapted for future versions of
> libpng.
> 

that is something I leave to the current maintainers :)

and now answering to some irc chats:

>mbiebl_	it only depends on libpng-dev though	23:20
>mbiebl_	why am I not surprised that something regarding the libpng transition is broken

well, it was uploaded *before* libpng-dev became a real package, so it is not surprising that I broke
experimental, specially because -release team asked us to do so.
"please push on experimental your solution for unstable", and that obviously meant to break in particular gdk-pixbuf.

I hope that will be fixed with the unstable upload and a binNMU.

>mbiebl_	the libpng transition is a never ending story of fail	23:27

I guess not anymore, now I have refactored a real part of the package, and I became to provide real packages, fixing multiarch and much more.

We got a "please go on" by the maintainers, and this is what we will do.

>Tanguy	By the way, do you know why is the libpng16 dev package named libpng-dev and not libpng16-dev? That library is >libpng16, not just libpng, is it?	23:34

we did ~100 NMUs just to change that bits, is this a good answer? :)
the better answer is to not provide a libpng16-dev *at all*, so people will be forced to use the main -dev package.

nobody can support more than one libpng implementation at the same time, so there is *no* real need of that number
as part of the development package (in fact I removed it also from the other binaries, except for the real library of course)

>With unversioned build-deps, the release team can just smack a big "binNMU the world" button, and if there are no drastic >API breaks, it all Just Works.	23:35

>Tanguy	Assuming the API does not change, right.

in that case, test rebuilds (as they have been done in 650601), and NMUs as needed.

>mbiebl_	_rene_: ask the ones which NMUed gdk-pixbuf for the libpng transition
> mbiebl_	_rene_: I wouldn't be surprised if something was broken along the way

before we had to force libpng16-dev in the NMU, now it isn't required anymore.
If you want to fix it, just binNMU it.
(that should make the future smooth in terms of next transitions)

>mbiebl_	Tanguy: the breakage comes from turning the virtual libpng-dev package into a real one	00:27
>mbiebl_	we could work around that by reverting the NMU and changing the libpng-dev depends to libpng12-dev again	00:27

why?
unstable has to have libpng-dev, the problem right now is for people mixing unstable and experimental, and will be
over as soon as the transition starts.

>Tanguy	mapreri, jcristau: Possibly, the fact is I have a package that cannot build with libgdk-pixbuf2.0-dev/experimental, >and I suspect all packages that use GTK+ will be in the same situation, and if a similar libgdk-pixbuf2.0-dev is uploaded to >unstable, it will result in similar breakage. Now, I think a simple binNMU of gdk-pixbuf in experimental may be just enough >to fix that, but I really do not feel c	09:21
>Tanguy	onfident in doing that myself, as it could very well just break more things.
>Tanguy	You can update my bug report if you want, as you certainly know better than me!	09:22

thanks for the bug report in first place, but you should be right there. a simple binNMU should be enough.

>mapreri	well, there have been 2 NMU of gdk-pixbuf  in experimental exactly to have it built against libpng1.6	09:23
>Tanguy	Well, not sure of what happens but it seems to still require libpng12.	09:23
>Tanguy	Let me check again.	09:24

yes, because a maintainer upload overridden the NMU, and in the meanwhile libpng16-dev has stopped to be provided in experimental.

So that breakage was somewhat expected.

>mapreri	there has been a maintainer upload on top of those 2 and now it is built against libpng12 again	09:24
>mapreri	let me check with one of the NMUers if he plans to nmu it again.	09:24
>Tanguy	Okay, that is why. Thanks.	09:25
>mapreri	Tanguy: Gianfranco said he will a look later and maybe follow up on the bug

Here I am

>Tanguy	Okay, thanks.	09:38
>Tanguy	While speaking of libpng, I noticed the library has soname libpng16.so.16, which would suggest it is really libpng16, >not just libpng, and that API stability is not supposed to be maintained whenever there is a libpng16 or so.

that would be a pain for the next transition, so big no here :)

for the later parts many people on -devel answered in a more appropriate way, so thanks jcristau and everybody else for
the great replies.

Sorry for quoting irc, but it was really easier to do.

(I hope I didn't sound too rude, but we are really near the start of the transition, just waiting for -release ack, and we spent already a lot of time on this, so I prefer to leave stuff like asking binNMUs or fixing experimental to other people, with a ~500 packages to check my priorities are somewhere else).

have many thanks, and sorry for the experimental breakage :)

cheers!

Gianfranco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20160403/d5c15dc8/attachment.sig>