Re: Future of Linux (.so contracts)
Alan Cox wrote:
> ...
> This is so that every app doesnt install their own version of python
> "just in case". That could be extended to all interpreters and some
> libraries probably and a farmed out approach would IMHO be good.
This is a notion of "software contract", if I understand correctly: a
tool intended to be used by other programs (interpreter, library) needs
a specification which should be adhered to in releases after the one I
built my application against (CORBA or Eiffel experts might have more to
say about this).
In order to attract ISVs, I think such a scheme needs to work very well
especially in the case of libraries, as it is quite easy to link
statically, disk space is cheap and resource consumption is not my
application's problem (this "single application" mentality is something
which might need consideration). Interpreters typically are (and are
perceived as) system-wide entities.
Having LSB attack the libc problem first seems very reasonable as it is
the one library which people should hesitate to link statically against,
but maybe does not bring the notion of a contract in full light. What is
exactly the contract/specification of a .so ?
A few raw considerations on the elements of the contract subject to
change:
- the programming language, e.g. the ABI for C and C++ is different, is
typically a non-issue because it is such an obvious change;
- the library name is the primary "handle" to the library, so if the
name changes we have another library and is again a non-issue;
- the soname (as in libc.5.3.12) is the second most important handle and
is central because it is where most changes are summarized.
If we say a library is a collection of functions which have a signature
and an implementation, the notion of change becomes:
1 - an implementation change which preserves the signature;
2 - a signature change (which may be construed as a deletion followed by
an addition, so anybody expecting to find the old function should not
find it) which almost always implies an implementation change;
The problem, of course, is that we check the signature but care about
the implementation (in the sense that we call a function for what it
does, although we should not rely on the exact means it uses to get the
job done). The implementation includes considerations such as
efficiency, i.e. application chose a function with more limited
functionality because it was more efficient, so implementation goes into
the contract in multiple ways (which is inconvenient).
IMHO, the problem of the .so contract is mostly about (1) once (2) has
been straightened out, i.e. once a signature change is performed in such
a way that the old function is not found, which is an easy test which
can be made automatic (I mean, the dynamic linker already tells you if
it does not find a function, and in C++ this includes the signature
because of name mangling).
On a more concrete note, when linking against an libfoo, should I link
against libfoo.so, libfoo.so.2, libfoo.so.2.6, libfoo.so.2.6.9 (maybe I
cannot do this last) ? What difference does it make ? Should it depend
on the specific library, as I assume it does ? When libfoo moved to
2.6.10, what changed ? (These questions are both about what happens and
about what *should* happen).
There are multiple points of view involved: the developer of the .so,
the application developer, the sysadmin installing .so system-wide
libraries, the application administrator installing .so shared by a
family of applications (this is typically system wide, but maybe a finer
granularity would be better ?), the power user installing libraries
under his home.
If this discussion seems applicable to the LSB I am willing to carry
this on further here, as it is one of my primary interests.
Davide Bolcioni
--
#include <disclaimer.h> // Standard disclaimer applies
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GE/IT d+ s:+ a C+++$ UL++++$ P>++ L++@ E@ W+ N++@ o? K? w O- M+ V?
PS PE@ V+ PGP>+ t++ 5? X R+ tv- b+++ DI? D G e+++ h r y?
------END GEEK CODE BLOCK------
Reply to: