Re: [PATCH] gdk-pixbuf: Fix libpng determinism issues

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2013-04-15 at 06:08 -0400, Colin Walters wrote:
> On Sun, 2013-04-14 at 16:33 +0100, Richard Purdie wrote:
> > On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
> > The more interesting change is:
> > 
> > https://git.gnome.org/browse/gdk-pixbuf/commit/configure.ac?id=d430bc4df3314a88cd538474d26ff7764d1f408c
> > 
> > and following that to the bugzilla 'For this to make sense, I changed
> > the order so that a version specific dep, such as libpng15 or
> > libpng12,
> > is found before just "libpng".'
> > 
> > I'm not sure I entirely follow that logic.
> 
> I added Matthias to CC as he touched this last then.
> 
> > I think the intent of the symlink is to provide the system with a
> > default libpng to use in the absence of a specific version requirement.
> > As the code stands today, each time a new libpng comes out, gdk-pixbuf
> > will need changes before it will be able to use it. 
> 
> Right, we need configure.ac changes, but the rationale behind that is
> that we'd also need *code* changes for each new major version of libpng.
> But it sounds like what you're saying is that gdk-pixbuf compiles and
> operates correctly with 1.6?  If that's the case, then the least
> invasive change here is to simply add 1.6.

It compiles and operates correctly as far as we can tell, yes.

Given that rationale, I'd suggest "libpng" should be dropped from the
list.

> Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1
> git tag to test, but it hard requires Automake 1.13.
> 
> Anyways, if it works (looks like the latest oe-core has it), then
> what about the attached?

It will make our builds work again for now until the next time someone
upgrades libpng and and then it will potentially silently start using an
old version in some builds :(.

We're therefore probably going to get stuck carrying a patch for
this :/.

> > In the meantime, it
> > will potentially link against something old, e.g. 1.2, since 1.2 is in
> > the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.
> > 
> > If we can justify changing this upstream, that would be great :). It may
> > be worth adding libpng16 into the list too so everything is covered too.
> 
> At this point I'm hoping the parade of libpng versions will
> settle down, so hopefully no further tweaking of the configure script or
> code will be required...

Its the case things silently break that really worry me.

Cheers,

Richard