Opened 17 years ago

Closed 17 years ago

#1905 closed task (fixed)


Reported by: Randy McMurchy Owned by: Randy McMurchy
Priority: normal Milestone: 6.2.0
Component: BOOK Version: SVN
Severity: normal Keywords: libpng

Description (last modified by Randy McMurchy)

Version increment to 1.2.12

Change History (11)

comment:1 by Randy McMurchy, 17 years ago

Status: newassigned

comment:2 by Randy McMurchy, 17 years ago

I played around a bit with this new release of libpng. It has an autotooled build system now, but I suppose we shouldn't use it. Even though the INSTALL file says to CMMI, the KNOWNBUG file identifies (rightly) that the library name doesn't represent the version correctly and that system library builders should use the custom makefile method used in past versions.

I feel it would be trivial to use the autotools installation and create properly versioned library names and symlinks, however, that probably isn't the 'right' thing to do. Unfortunately, the custom makefiles have been modified and the patch no longer applies and zlib and libm do not get pulled in properly. This is a trivial fix as well.

I'm going to play around a bit more and see how much hacking is required in to use the autotools and come out with a library named Right now libtool is creating a library named, which probably would be fine as the symlinks and would still link to all the packages looking for libpng.

comment:3 by dnicholson@…, 17 years ago

That's nice the libpng is now using autotools. On the zlib-devel list, the maintainer is considering moving to autotools, but there are some dissenters.

Anyway, it doesn't seem worth it to change the library version in my opinion. As long as the API hasn't changed, then the symlinks will pull in the correct library during building and older binaries will still find a compatible I think we should just go forward with the new versioning via libtool. Changing the version number now would just delay the inevitable.

comment:4 by Randy McMurchy, 17 years ago

I agree completely, Dan. However, should we just wait until 1.3.0? The Makefiles and other docs say that major versioning will take place in the 1.3.0 release. Everything will be probably straight CMMI then. And it could be now as well, as long as we are content with libpng12.a libpng.a

Probably time to move this discussion to -dev. I'll summarize our comments and post it up.

comment:5 by Randy McMurchy, 17 years ago

Milestone: 6.2future

Downgrading this bug to after 6.2. It gains us nothing to update this package in 6.2 other than headache. There are ABI/API compatibility issues where patches are already necessary. Simply not worth the update for the risk involved.

comment:6 by Randy McMurchy, 17 years ago

Summary: libpng-1.2.9libpng-1.2.10

Version increment to 1.2.10

comment:7 by Randy McMurchy, 17 years ago

I used this version at the beginning of a BLFS build on top of the current LFS SVN and so far everything is working as expected. There was a report that the 1.2.9 version had an issue with the Gimp, but I've not installed it yet, so I cannot say.

comment:8 by Randy McMurchy, 17 years ago

Indeed, there is an issue with the Gimp, who initially blamed the libpng author for breaking the API. But as it turns out, the Gimp has had code that libpng deprecated 4 years ago, and Gimp CVS is already fixed.

Either way, the fix is trivial, and I'm sending in a patch. So far, this is the only thing I can tell that this new version of libpng affects.

I'll continue testing more packages, but so far I am leaning to jumping the fence on this issue, and saying this version would be fine for 6.2

Not sure what is gained though, with this version.

comment:9 by Randy McMurchy, 17 years ago

Summary: libpng-1.2.10libpng-1.2.12

Version increment to 1.2.12

comment:10 by Randy McMurchy, 17 years ago

Description: modified (diff)
Milestone: future6.2

Now that 3 months have elapsed since the first update to libpng, and I've tested every package I can think of against the new libpng with good results, I can see no reason not to go ahead and update to the latest version for BLFS-6.2.

comment:11 by Randy McMurchy, 17 years ago

Resolution: fixed
Status: assignedclosed

Updated BLFS to libpng-1.2.12

I have been using it for a long time, and I cannot find one BLFS package that is incompatible with it. I can see no reason any longer to stay at 1.2.8.

Note: See TracTickets for help on using tickets.