Moving the thread off of private. On Sat, Aug 17, 2002 at 05:41:39PM +0200, Marcelo E. Magallon wrote: > 2. I don't understand your point. In fact I can't see what your point > is. I suspect Glenn can't either since the discussion when arround > in circles a couple of times. Gratuitous changes to library names are bad? We're still struggling with the png2 -> png3 upgrade, because of how much it affects; throwing a new soname into the mix is not helpful. > 3. After looking at the beta release of libpng 1.2.5, it builds a > library named libpng12 with soname libpng12.so.0. What's the > problem with that? As Havoc said, RH is even shipping packages > using that soname. RedHat has packages in Rawhide that use this name. That's not the same thing as shipping it, IMHO; it may not have made its way into a release yet. > We'd be actually *happy* with that. It forces upstream to declare > a dependency on a specific png release (you need to include > something like -lpng12 in your link line). That's *good* for us, > isn't it? Not particularly. It's the Debian maintainer's job to vet the upstream sources and make sure they work with whatever else we have in the archive. The libpng API changes very infrequently, and upgrading to a new library usually means doing nothing more than a recompile. Having upstream specify -lpng12 just makes more work for us. This soname change may help RedHat, but it doesn't help us at all. > is argueable. What's a hassle is getting upstream to convert to > the new version. For Havoc's purposes it'd suffice if the png > folks would rerelease libpng 1.0.x and 1.2.x using a) pkg-config b) > versioned include directories and c) library names of libpng-1 and > libpng-3 (or whatever makes Glenn happy). (Please reread what I > said: library names, not sonames). There'd be no issue if only the filenames had changed. That's not what's happening. Steve Langasek postmodern programmer
Attachment:
pgprThk9rfdd7.pgp
Description: PGP signature