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