[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help would be appreciated regarding libpng12.so/libpng.so.3



On Sat, Aug 17, 2002 at 10:34:54PM +0200, Marcelo E. Magallon wrote:

>  > 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).

That is the core of the objection.  So we are in agreement.

You can have parallel installable versions of the -dev packages without
changing the soname scheme.  (It's wrong to say this allows "parallel
installable versions of the lib" -- we ALREADY have that capability, with
every shared library on the system!  This matters only for -dev
packages.)

>  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).

I don't see that changing the library name is necessarily bad or good.
We in Debian don't need it, we have ways of working around these issues.
If other distros have weak packaging systems or differing approaches to
libraries that necessitate this, fine.  But let it be done in a way that
doesn't screw over those that have already begun migrating to libpng.so.3.

>  > 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.

I don't believe it saves us headaches.  Having versioned symbols saves us
headaches; anything else is a wash.

>  > 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.

I suppose I should look at upstream's changelog, to see when this soname
change took place.  If it happened 6 months ago, I guess we'll have to
pay the price for an inactive package maintainer.

Steve Langasek
postmodern programmer

Attachment: pgpQFcJLhJd2j.pgp
Description: PGP signature


Reply to: