Re: library versioning: making upstream policy, need debian evaluation.

[Rob Browning <rlb@defaultvalue.org>]

Junichi Uekawa <dancer@netfort.gr.jp> writes:

> One thing is that you cannot have Debian unstable to be unbroken
> unless you do coordinated upload.
>
> What you are describing is a situation that is very much like
> perl whatever->5.5->5.6->5.7 upgrade that every perl module had to be
> re-linked with the new libperl, and python 1.5->2.0->2.2 upgrade
> that every python module had to be recompiled for every 
> standard python version.

Actually (though not that it matters really) the idea I was
speculating about, with the hypothetically smarter linker and
packaging, was something similar to garbage collection for libraries
-- whether you might be able to design a hypothetical system that
keeps older copies of particular versions of libs around
automatically, at least until they're no longer needed by any other
binary on the system (of course you'd have to be able to decide
somewhat what "no longer needed" meant).

When launching an application, the runtime linker would pick a
consistent set of libs from the set of available libs, even if that
meant it had to chose older copies of the some lib to be able to form
a consistent set.

i.e. if foo were linked against libbar.so.1 and libbaz.so.2, and both
were linked against libcommon.so.4 and then libcommon.so.5 were
introduced, the system would still keep the copies of libbar.so.1 and
libbaz.so.2 that were linked against libcommon.so.4, and the linker
would still pick these copies when running foo (ignoring any new
copies of libbar.so.1 and libbaz.so.2 that might be added that were
linked against libcommon.so.5) until new copies of *both* libbar.so.1
and libbaz.so.2 are available that are linked against libcommon.so.5.
If only one newly linked copy, of either libfoo or libbar were
available, the linker would still use all the older copies of all
three libs for foo.

Of course this would require both the linker and the packaging system
to be able to distinguish and retain libs according to the library's
"interface number" *and* the set of interface numbers and names of the
sub-libs it depends on.

For example, libbar.so.1 would not be a complete description of libfoo
if libfoo were also linked against libcommon.  The complete
description would be

    libfoo (interface 1) (linked-to (libcommon (interface 4)))

because during a transition period, on the same system you might also
have

    libfoo (interface 1) (linked-to (libcommon (interface 5)))

The former copy wouldn't be elegible for removal from the system until
no package still contained an executable or library that needed it to
form a "consistent set".

Though I'm likely being overly naive, this approach might also have
the advantage of not forcing libraries to pick their sonames based in
part on the uncontrollable and unpredictable changes in sub-library
sonames.  Ideally a given library could just pick its soname based on
its own changes, and let the linker worry about the rest.

Anyway, thanks again.  I appreciate the discussion...

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