Re: library versioning: making upstream policy, need debian evaluation.
Junichi Uekawa <dancer@netfort.gr.jp> writes:
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Interesting. Thanks. I'm reading it with a particular eye toward the
guile 1.6 packages I'm about to release...
> libguile-dev, because that wouldn't make auto-rebuilders notice that
> something has gone wrong, and only people who experience strange
> segfaults of applications.
For guile-1.6, I was planning to release just a guile-1.6-libs package
that contained libguile.so.12 along with a number of other libraries
like libguile-srfi-srfi-4. All of the sub-libraries in this package
would be linked against libguile.so.12, and all of them use primarily
SCMs in their API. Since this implied that they were essentially
directly tied to the libguile soname, and would have to change
whenever it did, and since the upstream has planned to never change
the sonames of any of these libs during a stable guile series like
1.6, I figured such a "bundled" libs package would probably be
acceptable. Given your experience, would you agree or disagree?
I can always break out separate library packages, and I know that in
the general case that's the right thing to do, but given guile's
specifics, that seems like a lot of extra tiny packages when there
might be no point.
> There are other alternatives such as symbol versioning, and
> -Bsymbollic, but that does not address "SCM" being sent around
> everywhere.
In this case (or with something similar like an incompatible change to
GObject*'s), how *could* you fix it so that you don't end up with a
period where some apps are just broken for a while during the
switchover? In the general case I'm guessing you can't, but I'm
wondering if with a hypothetical smarter linker (or equiv) and the
ability to keep around older copies of libs (that only vary from the
new ones in their sub-linkages), you might be able to do a bit better.
Say you had an app foo which linked against libbar.so.1 and
libbaz.so.1, and both of these linked against libcommon. I'm
wondering if you could have an arrangement where the linker has a pool
of libs, some of which might even have the same name/soname and only
differ in their sub-library linkage. When trying to launch an app
like foo, the linker would try to find a "consistent set" of libs, and
it might actually pick an older copy of libbar.so.1 because the latest
version of libbar.so.1 is now linked against a newer version of
libcommon than is the only available version of libbar.so.1 (which the
linker also needs for foo). Of course this would mean you'd have to
store the libs more like a database, where you knew for each lib
(quickly) what its dependencies were, and you could keep several
copies of a given lib around, each of which just links against
different sub-libs. Just speculating... and thanks much.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: