Locating shared libraries

[skaller]

On Fri, 2007-06-15 at 17:28 +0100, Ian Lynagh wrote:
> Hi John,
> 
> On Thu, Jun 14, 2007 at 09:17:16AM +1000, skaller wrote:
> > 
> > The rules for package managers like Debian are that a component
> > library split into /usr/include, /usr/lib MUST have a man page,
> 
> I'm not sure where you're getting that from? Debian policy:
>     http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
> says
>     Each [...] function *should* have an associated manual page
> (my emphasis), and doesn't say anything about where the function is in
> the file system.
> 
> (it would be great if someone were to tweak haddock to generate suitable
> manpages, incidentally).
> 
> > and it MUST be a separately usable C/C++-callable component.
> 
> Have you got a reference for that? I can't see it in a quick skim of
>     http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> and the FHS.

No, it's the concept, not the letter of the Debian Law.

When you install a shared library, it is installed as a publically
accessible component to be shared.

That implies the interface is both documented and callable.

A library with undocumented symbols which are private to one
application such as GHC, or even a set of applications generated
by GHC, has no business in a directory intended for everyone to
be able to use it .. especially if the interface and ABI change
due to internal restructuring.

One way to measure this is: if you removed GHC and applications,
and there are (necessarily) no users of the remaining library
package .. the library package shouldn't be in the global public
place (/usr/lib+include etc).

In that case, the lib is an intrinsic part of GHC, and should be
in a GHC master package (sub)directory.

The problem with Debian is FSH standard doesn't really account
for packages like programming languages. If you look you see
for example Python lives in /usr/lib/python and ocaml lives
in /usr/lib/ocaml.

That's an abuse forced by a grossly inadequate directory model.
Ocaml and Python aren't libraries.

Solaris does this more correctly IMHO: packages live in a vendor
specific place, part of the /opt directory tree. 

Here 'opt' means 'optional', that is, not part of the core
operating system and utilities required to maintain it.

Anyhow, system like GHC, Ocaml, Python, Felix, etc, just do NOT
fit into the C model: bin/ lib/ include/ with or
without any versioning. They have bytecode, configuration,
and many other kinds of 'object' and 'development source'
and 'library' files, some of which may happen to be 'shared
libraries' but that's irrelevant. All those things need to be
managed in a (compiler-)system specific way.

The 'specific' way for C and Unix OS tools is the Debian FSH ...
it shouldn't be used for anything else.

Note that the Ocaml team is currently grappling with a second nasty
problem: Ocaml 3.10 uses a source incompatible pre-processor (camlp4).
So now, not only will a non-Debian installed Ocaml library or bytecode
executable be broken by an upgrade until the user recompiles from 
source (the usual situation for Ocaml) but now all sources using
camlp4 macros are broken until the end user edits them.

So the team is almost forced to support installation of 
non-conflicting separate versions now, just to allow migration.

Once you start versioning stuff .. splitting files into
subdirectories like bin/ lib/ include/ is a nightmare.
Note that the 'include' part of that utterly fails for
C code anyhow.. so even the basic model is flawed for the very
kind of code it was designed to support.

The bottom line is Debian FSH is archaic and work should be
done to eliminate all user level packages from it: only core
OS packages should be allowed in /usr.

IMHO the best workaround for this problem is to use a thunk/
driver script in /usr/bin and put all the real stuff in a single
version specific compile install directory whose location is
entirely irrelevant. This is more or less what gcc does, and the
gcc model works very well I think. Multiple gcc versions, including
cross compiler, can be installed and 'just work' with all the
right bits glued together.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net