Re: pkgsrc: libidn (The problem nearly all the GNU libraries)

[Vincent Stemen <vince.dragonfly@xxxxxxxxxxx>]

On Sun, Mar 22, 2009 at 03:24:53PM +0200, Hasso Tepper wrote:
> Petr Janda wrote:
> > /usr/libexec/ld-elf.so.2: Shared object "libidn.so.11.5.39" not found,
> > required by "konqueror"
> 
> That's how pkgsrc works at the moment. I agree that it should handle the 
> situation much better, but ...

This has been a thorn in my side for a long time now.  Applications
should *not* be linked to the most minor version of a library.  Although
I have not had time to investigate to confirm if this is a pkgsrc issue
or an issue with the GNU build environment.  It seems that most of the
add on GNU apps in pkgsrc are suffering from this problem in recent
years.

Applications should only be linked with a soname of the major version of
the library, i.e. libxxx.so.N, like the libs in /usr/lib, so that every
application installation or upgrade does not break everything else
because of minor library version upgrades.


> > What happens is that all the packages were compiled against this
> > version of libidn and when it gets updated everything shits itself. I
> > think packages should compile against a symbolic link(libidn.so) to
> > libidn that doesnt have the version in it.
> 
> And if the library contains API/ABI incompatible change?

Minor version changes should *not* have compatibility changes.  Only
major versions.  Somebody who is maintaining the build environments has
lost scope with that or never understood it.  I see applications linked
with a soname something like

    libxxx.so.1.12.00.2.8

Then you install an app that is linked with a soname of something like

    libxxx.so.1.12.00.2.9

And either the application does not work because the dependencies
include something like

    libxxx>=1.12

which libxxx.so.1.12.00.2.8 satisfies, rendering the package dependency
list useless because the library does not get upgraded,

or

the library ends up getting upgraded, unnecessarily breaking every other
application that was linked with libxxx.so.1.12.00.2.8.

Or, we find ourselves having to manually make a backup copy of every
library to accommodate existing apps for every new application
installation because it might cause minor library upgrades.  That is, as
I mentioned above, if the new applications dependency list even works.

If the authors/maintainers make API compatibility changes to minor
versions, they should be chastised and/or, have bug reports filed.
I consider this a critical issue that merits consideration of branching
the library project or choosing a different library, if the maintainers
continue to make compatibility changes to minor library revisions.  But,
I don't think most of them are.  This seems to be primarily
a build/linking problem.