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@xxxxxxxxxxxxxxxxxxxxxxx > 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
Attachment:
signature.asc
Description: Digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
