fre 2011-11-04 klockan 13:12 -0400 skrev Tom Lane: > 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 With this data my gut feeling is to go for 1.5 in rawhide/f17. 1.4 is declared legacy, with no clear support schedule and certainly won't evolve at all with any new features. And it also marks the mentioned direct struct interface as deprecated anyway. Documentaiton on how to adopt application code to work properly with libpng 1.4+ is readily available. As you plan on providing 1.2 .so library for binary compatibility with old packages this pretty much reduces to an FTBFS for those packages where upstream is not yet compatible with libpng 1.4 or later. (use of a deprecated interface giving compile warnings is not seen as compatible in my eyes). > (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
