Re: Help would be appreciated regarding libpng12.so/libpng.so.3
>> Steve Langasek <vorlon@netexpress.net> writes:
> Moving the thread off of private.
Thank you.
> > 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.
In general yes. What Havoc is after (and I know this by reading his
posts on some gnome mailing list) is parallel installable versions of
libpng. AFAICS Havoc is the one behind the whole libfooN bussiness. I
might be misplacing authorship, but I've gotten the feeling he's one
who's been pushing that.
Having parallel installable versions of libraries is in general a good
thing, even if the names of the library look ugly. It is a very nice
thing to have on multiuser machines. Everyone seems to want something
different installed.
I concur with you insofar I don't see the need for changing the
*SONAME* of the library (AFAICS the idiotic SONAMEs come from
libtool). But changing the name of the library is ok and I really fail
to see a major reason why this is bad. Sure, it breaks builds, but
that's it. Or do I miss something? (I'm not saying that breaking
builds ins't bad, but it not as bad as breaking people's systems).
> 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.
Yes, bad wording on my part.
> > 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.
Uhm... in this case, yes, that's possible, you are right, since libpng
2 and 3 have compatible APIs. PNG suffers from bad design (it exposes
processor-specific functions in the API) and bad planning (see this),
but we can't do much about that.
> 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.
But it saves us headaches. I still hold it's better if upstream
calls for a specific version since that solves the inter-distribution
operability problem at the root level. If upstream says they want
libpng 2, they get libpng 2. And every distribution gets the same. If
it happens that some widely used library calls for libpng 2 while
everything else commonly used in conjunction with this hypothetical
library uses libpng 3, then the distributions will put pressure on
upstream to change the soname name and call for libpng 3.
We have two problems to solve: the short term one (what do we do about
this current situation) and the long term one (educate upstreams about
this kind of thing). If get can get help from other upstreams in order
to achieve the second goal, that's a good thing on my book.
> This soname change may help RedHat, but it doesn't help us at all.
I think Junichi said this is not a recent change. Apparently we've
been skipping newer upstream releases because of this change. Our
libpng is 1.2.1, upstream's beta is 1.2.5. Junichi said fixes are
being actively backported. That sounds like more work for our people,
which doesn't help us.
--
Marcelo | Item 42: Use private inheritance judiciously
mmagallo@debian.org | -- Scott Meyers, Effective C++
Reply to: