Upgrading libpng: shall we move to 1.4.x or 1.5.x?

Dr Andrew John Hughes ahughes at redhat.com
Fri Nov 4 19:41:20 UTC 2011


On 13:12 Fri 04 Nov     , Tom Lane wrote:
> I have been looking into replacing Fedora's obsolete version of libpng
> (1.2.x release series) with something more modern.  The possible choices
> are the 1.4.x and 1.5.x release series.  The 1.5.x series adds some more
> features that 1.4.x did not have, but it also poses significantly more
> migration problems.  The reason is that 1.5.x no longer exposes the
> contents of the library's internal "png_info" struct.  Direct access
> to fields of png_info has been deprecated for a long time, in favor of
> using accessor functions, but up through 1.4 you can get away with it.
> 
> I did test rebuilds in mock of all rawhide packages that are reported to
> be dependent on libpng.  Out of 964 packages with dependencies on libpng,
> we have:
> 
> Packages that rebuilt successfully with 1.5	658
> Packages that FTBFS for non-libpng reasons	186
> Packages that rebuilt with 1.4, but not 1.5	74
> Packages that need help even with 1.4		46
> 
> (The non-libpng failures seem to mostly be due to the recent upgrade to
> glib 2.0.  Some of those probably have libpng issues as well, but didn't
> get far enough in their builds to expose them.)
> 
> About half of the "need help anyway" group may just need their
> BuildRequires to be rebuilt first --- it looked like they had no
> source-code dependency, but were just absorbing "-lpng12" from library
> link flags reported by other packages.  I built each package independently
> rather than trying to chain the builds, so this wasn't catered for.
> 
> The vast majority of the 74 packages that would need extra work if we move
> to libpng 1.5 are trying to access the png_info struct directly, and so
> would need patches to use the accessor functions instead.  This is work
> that should be done and upstreamed anyway, but if we move to 1.4 we would
> not have to do it Right Now.  It looks like it would be a fairly large
> amount of work, too --- I count 1164 "incomplete type" failures in the
> build logs for those packages, and it's quite likely there are more in
> source files that the build runs didn't get to.  On the other hand, if we
> move to 1.4 there will not be any pressing reason for these fixes to get
> made, and so I'm not sure that we'll be any better off when we try to move
> to 1.5 later.  Another point is that we'd have to build these same 964
> packages over again if we plan a two-stage upgrade.
> 
> Any opinions on which way to jump?
> 
> In either case, as per the discussion at
> http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html
> I plan to provide the 1.2.x libpng shared library (and only the library,
> not its devel support files) in a libpng-compat subpackage for the time
> being.  So existing programs that depend on 1.2.x will continue to work,
> but it won't be possible to rebuild a package that has source-level
> dependencies on 1.2.x until those are fixed.  I think this is enough
> to avoid needing a special build tag for staging the rebuilds.
> 
> 			regards, tom lane
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

FYI, Gentoo already went to libpng 1.5 and so have patches floating around
for a lot of stuff that breaks.  A lot of the issues I found when rebuilding
against 1.5 was the hardcoding in libtool files rather than any source code
issues, which means they have to rebuilt in the right order (e.g. a high-level
GNOME package doesn't build because one of its dependencies hasn't been rebuilt
and it still has the old -lpng12 hardcoded).

We already fixed IcedTea/OpenJDK to work with libpng 1.5 as a result
of Gentoo's work, and those packages should already be in Fedora.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111104/c961a6b8/attachment.bin 


More information about the devel mailing list