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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
