Kevin Fenzi <kevin(a)scrye.com&gt; writes: > Some quick questions: > Whats upstreams schedule like? How long will 1.4 and 1.5 continue > to be supported, and when do they plan on a 1.6? 1.4 will be supported for a long time, though presumably not as long as 1.5. I don't think there are any active plans for an incompatible 1.6 at all.

My own agenda though is that I'd like Fedora to be on 1.5 in the next release or two, so that Red Hat isn't in a position of still needing support for 1.4 eight or ten years from now due to it being in future RHEL branches.

> Is there possibly a way to switch to 1.4, but warn (buildtime) about > this going away soon, etc? Well, 1.4 does put __attribute__((__deprecated__)) labels on all the png_info struct fields. (They're actually there in the 1.2 headers as well, but not enabled by default.) However, how many Fedora maintainers worry about fixing mere compiler warnings? I know I can't claim to spend any time on that, except with my upstream hat on.

Once upon a time, Tom Lane <tgl(a)redhat.com&gt; said: > Any opinions on which way to jump?

How hard is it to fix source that accesses the fields directly? Do all the fields that were previously exposed have direct accessor functions?

Since all the packages that depend on libpng would have to be rebuilt twice if you don't go to the latest version now, I'd say go ahead and get it over with once (i.e. go to 1.5).

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(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

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.

Nils Philippsen <nils(a)redhat.com&gt; writes: > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote: >> 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. > Any reason why the compat package ships the libpng-1.2.pc pkg-config > file? Yeah: I tried it without first, and found that I couldn't rebuild anything. There are boatloads of packages that have pkgconfig(libpng12) as an RPM-visible dependency, so if the compat package doesn't supply it, those packages won't install and you can't rebuild any of their dependencies. I have no idea why it was considered a good thing for RPM to track this type of dependency, but it does.

> This made one of my packages use 1.5 headers, then later on > attempt to link to libpng12.so which failed. I doubt that's coming from the libpng12 pkgconfig; more likely, you have some other package you're depending on that needs to be rebuilt first, because its pkgconfig file currently says to use -lpng12 in link commands.

With

pkgconfig(libpng) = 1.2.46 pkgconfig(libpng12) = 1.2.46

once libpng12.pc gets removed from the distribution, the dep-chains break, of course.

As a temporary work-around, you could have provided that thing manually in the libpng-devel upgrade instead of including the actual libpng12.pc file:

Provides: pkgconfig(libpng12) = %{version}-%{release}

Any configure script or .pc file using a hardcoded "libpng12" name would fail to build, but that would be better IMO than offering an incomplete broken compat package that confuses the buildroots.

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

Go for it, I think it makes sense. For those that don't support 1.5 they can stay against the compat in the mean time.

I've been doing driveby rebuilds for some of these that happen to have been in a default install on my machine, but we still have a huge pile of things built against the old libpng in rawhide: [ajax@f17 cairomm]$ repoquery --whatrequires libpng-compat | wc -l 786

Does anyone object to me just kicking a mass rebuild for this? I'll happily follow up with the list of build failures.