Re: library versioning: making upstream policy, need debian evaluation.
> libgwrap-glib???: (provides libgwrap-glib.so.???) (depends libguile.so.12)
> The question is what goes where the ??? is above? If we pick "1", for
> the soname, then as soon as the gwrap maintainer uploads the new gwrap
> packages and they're installed, both gnucash and some-other-app are
> broken, even though all of their dependencies are still satisfied.
> Doesn't debian forbid this this? If so, if a "1" is not acceptable,
> then what would be, who chooses it, and when -- "make dist time",
> "build time"?
My proposed solution, which has been somewhat enforced, and
seems to work within Debian as a distribution, is to control the
sonames in such a way so that "1" can be "1",
but it will be "2" when a new libguile comes out.
libgtk+1.2 applications were linked with libpng2,
libgtk+2.0 applications are now linked with libpng3.
Inter-library dependency and soname consistency, and interface
consistence is manageable only through some central mechanism.
The recommendation provided in libpkg-guide is to use
libguileINTERFACEVERSION-dev, so that other packages which
build-depend on that libguile Build-Depending on libguileINTERFACEVERSION-dev
will be unbuildable when new libguile with new soname comes out, so that
we can fix their sonames also, coordinating with the upstream.
Note that it is pointless for packages to Build-Depend on
libguileINTERFACEVERSION-dev | libguile-dev, because that wouldn't
make auto-rebuilders notice that something has gone wrong, and only
people who experience strange segfaults of applications.
There are other alternatives such as symbol versioning, and
-Bsymbollic, but that does not address "SCM" being sent around
Debian as a distribution, being a very big distribution can help
contribute to integrity of free software package through this
kind of soname management.
Having libgtk+2.0 scheme is only advantageous for keeping multiple
development versions around, and does not much help with libguile