Future of Linux (.so contracts)

Davide Bolcioni davide.bolcioni at 3di.it
Tue Nov 17 01:50:09 PST 1998


Christopher Hassell wrote:
> 
> On Thu, Nov 12, 1998 at 10:11:31AM +0100, Davide Bolcioni 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).
> 
> Also known as the "*.DLLs that you shouldn't have uninstall'ed!" problem.
> (If software has its own version of Common-Use stuff, should it overwrite?
> If it is un-installed, should it delete its own stuff?  Should it squirrel
> away a copy of the old stuff?  Should it ask you arcane questions like "Do
> you want gtk-1.5 or gtk-1.6.1?").  All of those go along with the "software
> contract" or a platform query.
 
> I am in favor of RPM as a common-use package system if maybe *ONLY* because
> it promotes a widely-accepted versioning scheme and even pretty reliable
> distributions.  Sending along "stock" rpms with your package would be a
> *very* nice and simple deal.  Relocatible packages would allow use of your own
> dirs if you must use an old/too-new version.

I wonder if the following approach would be acceptable: instead of the
foo package depending on libbar, depend on foo-provided libfoobar and
provide two conflicting libfoobar packages, one which just symlinks with
the existing libbar and one which squirrels away its own copy somewhere
and symlinks there. Some care may be needed for filesystems which are
partitioned (e.g. I personally have /boot, /tmp, /usr and a couple
others all on different partitions, some with md, and experienced minor
glitches with some packages, especially at boot time).

> Right now our CDE sends along a *lot* of common/free shared libs.  It is not
> clear (at least not until we get our new RPM deliverables out) whether we
> should just assume a NewerVersion is better or not.  Also, should we set
> aside the libraries we find or should we wipe 'em out (because we've tested
> against our own compilations).

IMHO, you should leave that decision to the package manager (the "rpm"
program in case of RedHat); if you "set aside" (?) or wipe out newer
libraries installed on the system, an existing application relying on
these libraries might fail (a Windowish behavior which, as a sysadm, I
personally would not appreciate). Replacing an older version is more
acceptable because it is the standard behavior everybody is used to,
given user confirmation.

> Any comments on freeish library/script-language package compatibility?
> I think that's the main issue to conquer: tests for determining if a working
> version of XYZ script or a valid version of jpeg3d.so.84.3.0 are out there.
I believe that developers of both interpreters and libraries would
welcome test suites or additions to such, especially from a third party
which might point out something they did not think about, and would be
happy to include them in subsequent releases. I thought LSB had
something like this in mind for libc.
 
> ] 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.
> 
> Libraries are also system-wide.  Some features appear *because* of new
> libraries (jpeg/tiff/png/gtk/imlib) and updating a shared library might be
> *the* one way to make it more stable.  Note also that LGPL requires that any
> recipient be able to  *re-link* against newer LGPLed libraries if
> proprietary code uses one in the first place.  If not, then you're not
> making an LGPL-compliant link and -all- the source code should then be GPL.
Agreed.
 
> If you want an example of *very* important libs, take the hybrid: tk and tcl.
> They are both libraries and a scripting language.
> 
> (deleted segment...)
> ... (standardized library names, interpreter names) ...
> ... (quantifying changes (improvements/alterations) to an API ...
> 
> Services offered by a lib should be compat-backwards and changes orthogonal
> IFF the version number is within a linkable distance... tho I don't know about
> trying a two-tiered link version system.  (i.e. link against libleep.so.N
> and try to load libleep.so.N.N (a different linknamed library)) dynamically
> via symlink.
Agreed, the GCC-HOWTO says that current practice is to link with
libfoo.so, which actually becomes a link against soname=libfoo.so.3
because that's what's on the system the link occurs in (following
symlinks) and then on the system the binary is run the soname is
resolved following symlinks. I just wondered if this scheme was enough.
 
> ] .... 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 ....
> 
> That is a pretty good test.  Still, it is *not* fun to find one small
> program from a list of a hundred failed.. and it only did that because of an
> old/new shlib.
> 
[ ... snipped, details of .so handling are in the GCC-HOWTO ... ]
> They will, however, get automagically updated from, say, libc.so.5.3.12, if
> a later libc.so.5.* is installed and ldconfig is run.
Agreed as far as the current practice goes; I am still wondering if a
better way exists.
 
> ] 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.
> 
> I think the main idea is to find a namespace (rpmdb?) or a test-script space
> for various external-support pacakges.  Even /usr/dict/words is not a
> requirement, and neither is fortune nor several other arbitrary utils.
> 
> What can we offer commercial vendors, so that PhotoShop and/or BigOffice works?

I have this vague notion that a commercial vendor should not, in its own
and in everybody's interest, depend on GPL (read OpenSource) resources
(more specifically: it should not ship binaries linked against
libjpeg3d.so.2) directly. This dependency should go through a binary
compatibility library, whose sole purpose is strict binary compatibility
and whose source should be available. This library can be written by the
ISV interested in it, by whoever develops the GPL library ligjpeg3d.so
or by a third party such as the LSB in the case of wide usage, according
to circumstances.
  We should not worry about binary compatibility for GPL software;
binary releases should go through a compatibility layer instead, because
the development of GPL software is too quick and incremental for them.
This compatibility layer should be available in source form because it
must keep up, but maybe it needs not be GPLed, i.e. the ISV might retain
some copyright on it (although it does essentially nothing). Having
multiple compatibility libraries should not be a big problem since they
are not a shared resource, although some problems are likely to come up
anyway; the impact however would be limited instead of system-wide.
  When a new version of libjpeg3d.so comes out, whoever maintains the
compatibility library waits for complaints and then sets out to return
to compatible status (I am assuming that if a test suite existed, it
would have been used to test the new version by whoever produces
libjpeg3d.so), providing useful input to the development of libjpeg3d.so
in the process.
  Of course, binary-only releases would take a small performance penalty
from this compatibility layer, but it is the price to pay for binary
compatibility. You probably pay for it (dearly) on Windows, for example,
although you're not told about this detail.
  As a final note, I think some desiderable properties of whatever
scheme is constructed should be:
- it should worry about backwards compatibility to binary-only releases;
- it should not saddle development of components with binary
compatibility requirements, i.e. development of libfoo.so.3 should not
worry about compatibility issues with .2 (this will not occur with GPL
components anyway);
- binary compatibility is addressed specifically, e.g. with a
compatibility library providing a stable interface (one year ?);
- static linking is frowned upon (because statically linked code might
access shared resources the wrong way, e.g. /etc/passwd accessed
directly but I have PAM);

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



More information about the lsb-discuss mailing list