libpng: update to 1.4.x, tweak livecheck

[rmsfisher@…]

Running "port livecheck libpng" reports that libpng has been updated.
For some reason MacPorts seems to be sticking to the "previous" rather than "current" series of libpng releases, so the livecheck result of 1.4.0 rather than 1.2.xx is a little misleading.
If/when libpng is updated to 1.2.42 (the most current version), please improve the livecheck expression to look for releases in the correct release series.

[jmr@…]

1.4.0 was only just released (2010-01-03); Ryan may well want to update the port to it.

[blb@…]

I'm guessing the update (from the  ReadMe)

Enabled iTXt support (changes png_struct, thus requires so-number change)

means all dependents will need a rev-bump, like for jpeg.

[ryandesign@…]

I updated libpng to 1.2.42 in r62356 while I figure out how I want to handle 1.4.0.

[ryandesign@…]

The update to libpng 1.4.0 is straightforward enough, but yes, the library name is now libpng14.dylib and all the ports link with libpng12.dylib so they'll need a revbump right after.

[jmr@…]

You can  apparently build both libpng12 and libpng14 from the 1.4.0 source.

[ryandesign@…]

Hm, yes I see the ANNOUNCE file says I can do this. But I don't see how to do this. Also I'm guessing the two versions would have to be built separately, with two separate configure and make invocations, complicating things (though not insurmountably; we've done that before, e.g. in php5 port and the php5extension and muniversal portgroups).

[ryandesign@…]

I think we'll just update to 1.4.0 and revbump all dependents. When doing so, remember to revbump and add libpng dependencies to the wine ports. Probably want to also "otool -L" all my installed ports afterward to see which ones still link with libpng12.dylib without declaring a dependency, so they can be revbumped too and have the dependency added.

[jmr@…]

Here's a patch that updates libpng to 1.4.1 and adds a new non-conflicting libpng12 port based on the old version. Also removes muniversal because it is doing nothing useful (the configured source for each arch does not differ at all apart from the arch flags).

[rmsfisher@…]

Ryan S.,
I have built cairo against libpng 1.4.2; it compiles and runs properly but its dependents (pango, gtk2, py26-cairo, libglade2, and py26-gtk2) must all be rebuilt to rely upon libpng14.
Tons of ports depend upon libpng (172 from 'port echo depends:libpng |cat -n'); revision bumping each of those ports (and possibly a handful of those ports' dependents) would be quite an undertaking.
Josh's approach in the above diff is simpler and should allow ports to transition to libpng 1.4 far more smoothly.
Are there any specific issues that are delaying that move?

[ryandesign@…]

You're right, there would be a lot of ports to revbump, not just those that list libpng as a dependency, but also those that indirectly use libpng, which we may only discover through analyzing our installed ports, or worst case through bug reports later. But we've successfully used this revbump strategy with jpeg 7 and again with jpeg 8.

My concern with Joshua's proposal is the hack for deactivating libpng @1.2.x before installing libpng12. It can be simplified a bit now that MacPorts 1.9.0 is out, but it's still using commands that were not meant to appear in Portfiles. Though it's not like we haven't used various internal MacPorts methods in other ports before. (I know I'm guilty of this with php5.) And perhaps keeping both libpng12 @1.2.x and libpng @1.4.x is a good idea for now, since probably some software still doesn't work with libpng 1.4.x yet.

[rmstonecipher@…]

Cc Me!

[rmstonecipher@…]

What should be done with this ticket and the above patch now that MacPorts 1.9.1 has been released?

[ryandesign@…]

I would prefer to handle this upgrade in the more traditional way: update the libpng port to 1.4.x, revbump all ports that use libpng, and later, if needed, add a libpng12 port for those ports that are incompatible with libpng 1.4.x. This way we can be sure which ports are linking with which version of libpng.

While Joshua's proposal might seem to be smoother, I worry that it means that ports built before this change will be using libpng 1.2.x, but rebuilding those ports would probably re-link them with libpng 1.4.x, possibly causing problems or incompatibilities then. We won't know until such a rebuild happens. I'd kind of rather have all those rebuilds happen now, via a revbump, and get it all out of the way.

[rmstonecipher@…]

With permission I would like to apply the attached patch to the Portfile to upgrade the ported libpng to 1.4.5.
1.5.0 is available upstream, but the homepage warns against using it due to a bug that will be fixed in 1.5.1.
With an estimated release date of 2011-01-20, updating this port now should give us a few days to identify which ports need libpng 1.2.x and which can utilize libpng 1.[4,5].x.
May I give it a try?

[rmstonecipher@…]

libpng 1.4.5

[jmr@…]

also remove muniversal and redundant use_parallel_build

[jmr@…]

Go ahead, this is long since timed out. But use the patch I just attached. And don't forget to rev bump all dependents at the same time; you can use the script attached to #23260.

[ryandesign@…]

If you feel up to tackling this, please go ahead. Good luck!

[rmstonecipher@…]

Updated Portfile and scores of revision bumps committed in r75159.