|Summary:||RFE: libpng 1.5.2|
|Product:||[Fedora] Fedora||Reporter:||Michael Cronenworth <mike>|
|Component:||libpng||Assignee:||Tom Lane <tgl>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||agpotter, erik, hhorak, itsme_410, jnovy, mid9090, nphilipp, tgl|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-07 00:36:51 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Michael Cronenworth 2010-06-29 17:51:07 UTC
Description of problem: libpng 1.2 is going EOL at the end of 2010. Per bug 608644 comment 10. Fedora is about being First, so libpng 1.4 is a natural fit for Rawhide.
Comment 1 Michael 2010-11-13 14:46:53 UTC
Agreed. Not only that, there are features like iTXt chunks that aren't available in 1.2. That means you can't write software to take advantage of XMP tags inside iTXt chunks to specify EXIF data. I have software where I have to manually keep a separate version of libpng 1.4 to compile against, and it is quite annoying considering iTXt support has been in libpng for over 10 years!
Comment 2 Michael 2010-11-13 15:20:20 UTC
An additional comment. Even if some packages are not ready for libpng 1.4, the two (or really three if you include 1.0) versions of the library can easily live side by side. Just ensure that the symbolic links for libpng.so and png.h pngconf.h still point to the libpng12 files and not the libpng14. Packages that support libpng 1.4 can manually specify libpng14 until version 1.4 is accepted as the base. Additionally, the libpng maintainers claim: "A new private header file that is not visible to applications has been created, to improve our ability to maintain binary compatibility among future libpng versions."
Comment 3 Nils Philippsen 2011-03-17 15:02:52 UTC
Meanwhile, libpng-1.5.1 is out. Is there any reason, not to put this in Rawhide (F-16) at this point?
Comment 4 Tom Lane 2011-07-14 17:14:45 UTC
*** Bug 703063 has been marked as a duplicate of this bug. ***
Comment 5 Ranjan Maitra 2011-09-14 13:09:47 UTC
Any news on these updates/RFEs?
Comment 6 Tom Lane 2011-09-14 14:57:29 UTC
My plan is to push libpng 1.4.x into F17, and then depending on how that goes, maybe 1.5.x in F18. I'm not convinced that 1.5.x is ready for prime time as yet, but maybe next year it will be.
Comment 7 Ranjan Maitra 2011-09-14 18:52:05 UTC
Why not put it on rawhide at the least? is there a reason? there do not seem to be issues in 1.4.x. just perplexing that Fedora has been so slow since the RFE (from 2010), and many features are missing in 1.2, but are in 1.4 and 1.5. thanks for looking into it!
Comment 8 Erik Logtenberg 2012-01-16 13:47:37 UTC
I see that there are libpng-1.5 packages for F17 on Koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=105 However there hasn't been a libpng-1.4 release, we are going straight from 1.2 to 1.5 it seems. Rather unfortunate, since I was specifically looking for an 1.4 rpm because Cadsoft Eagle requires that version.. Are there still plans to release a libpng-1.4 package somewhere along the way?
Comment 9 Tom Lane 2012-01-16 15:17:20 UTC
(In reply to comment #8) > Are there still plans to release a libpng-1.4 package somewhere along the way? I have no such plans. Fedora is not generally intended to ship obsolete versions of software. The idea of shipping 1.4.x in F-17 was only intended to reduce the amount of pain involved in getting to 1.5, but after looking into it more carefully it seemed that it would result in more work overall, not less.
Comment 10 Nils Philippsen 2012-01-18 14:47:22 UTC
(In reply to comment #8) > Rather unfortunate, since I was specifically looking for an > 1.4 rpm because Cadsoft Eagle requires that version.. AIUI, Eagle is not RPM-packaged, so you can simply download the tarball of libpng version 1.4, build and then install it into /usr/local.