Re: debian packaging of findlib
On Sun, 18 Feb 2001, Sven LUTHER wrote:
>Well, yes, but you are not using a linux distribution, with packages that have
>to conform to the same installation guidelines.
>
>Then, maybe you use some distrib (maybe rpm based) that don't give you the
>possibility to easily do your own packages that are integrated with the main
>distribution.
>
>That said, i understand you, but we are in different world, you want to use
>ocaml programs in any environment you use, while what we are trying to achive,
>ios that the user, who don't want to worry about things like you, can use the
>system, and have the guarantee from the packager that everything is in its
>right place, and will cooperate and speak with each other ocmponent without
>problem. Fot that we have to conform to some standards.
Yes, you are right, these are not my standards. I have a developer view, and
one of the goals of findlib is to minimize the time I spend with writing
configure scripts or intelligent Makefiles or detailed build documentation. I
want to make it better than in the C world, and so I have written a generic
tool that simplifies these tasks.
But also plain users benefit from findlib. Imagine somebody downloads a program
from somewhere, finds that it is written in ocaml, and installs the debian ocaml
packages to be able to compile it. Our downloader is not a developer, and ocaml
is a new word for him. If the program has a findlib-complying Makefile, he
needs only call "make" and the program compiles. No configure scripts with
dozens of parameters, no variables to set, no environment to understand.
Standards are a great thing, but they must match what users want. I fully agree
with you that a package system should guarantee the integration of the
components.
>> >Ok, now on with the proposals, ...
>> >
>> >The problem with ocaml packagging and findlib is as follows :
>> >
>> > * 1st, for installing, it would not do to use findlib, since the packages are
>> > built on another system than the one they are used on, and are not
>> > installed as root, and in another directory than the one they would finally
>> > be in.
>>
>> Most packages are relocatable (no paths compiled into the archives/executables).
>> The notable exception is findlib itself.
>
>Err, .
>
>the probmlem is that ome packages do things like that :
>
>install:
> $(OCAMLFIND) install xxx yyy zzz
>
>or something such.
>
>which cannot be done when findlib is not installed ...
Maybe there is a misunderstanding; I don't know much about debian packages. Do
they install themselves from source? In this case this installation method
requires that findlib is already installed. For a purely binary package it
is not required.
>> First some general notes about findlib:
>>
>> Some important packages use findlib to resolve dependencies. For example:
>>
>> - PXP needs netstring and optionally wlexing
>> - netstring needs str
>>
>> So when I compile a program using PXP, I need not know the direct or indirect
>> dependencies. Imagine what happens if I change netstring someday such
>> that it bases on pcre and not str for the regular expressions (or that I add
>> other prerequisites): Without findlib you have to change the Makefile of the
>> program applying PXP, with findlib everything works out of the box. The task of
>> findlib is information hiding on package level.
>>
>
>Yes, i understand that, from your perspective, but from the dbeian
>perspective, this is handled by the packages system, which provide build
>dependencies and normal dependencies, so we really don't need findlib in the
>nomral usage.
>
>The only real usage is for people doing developpment in ocaml, using not
>packaged packages, or own-developped packages, and want to use the facilities
>of findlib.
I don't believe that the debian package system is smart enough to handle _this
type_ of dependencies. A dependency is not only a precondition that can be
checked whether it is true or not. For example, if I compile a program using PXP
with
ocamlfind ocamlc -o sample -package pxp -linkpkg sample.ml
the dependency analysis yields that a number of libraries must be linked into
the executable, resulting in an effective command such as
ocamlc -o sample -I /xxx/pxp -I /xxx/netstring -I /xxx/str
str.cma netstring.cma pxp.cma sample.ml
which is extracted from the meta-information data included in the packages.
This is not only useful for developers! Also casual users who only want to
compile programs by third parties benefit from this analysis because they do
not need to configure anything, at least regarding the development environment.
>Sure, we have all this in the packaging system, even apt-get source -b will
>downlaod the needed version of packages that are needed to build the one you
>are building. Since this is done on a distribution level, it will cover more
>things than what you cover with findlib.
This is a very debian-centric view. Maybe I do not understand your point: Is
the solely task of a debian package to build another debian package? I only
need the compiler and the libraries to _build_ (at some point) applications. And
it is very likely that the app is not (yet) debianized.
>> Back to your question. For most packages you do not need a postinstall script
>> because they are simply relocatable: move the directory to the location you
>> want. The user of the package is free to manually set directories etc for his
>> own project he wants to compile, or to call on findlib's help.
>
>err, the post install script will register the ocaml modules and libraries
>with the findlib meta package, even without findlib being installed, so that
>when later you install findlib to use it for your own developpment, all the
>debian modules will be available for it, not only those witten by you and the
>few other that support findlib. (in particular, there is no findlib support in
>the inria developped libraries, isn't it ?)
Well, you can implement such a registry by having a special place for all the
META files, and if findlib is being installed, these files are moved to their
final place. You can do it this way, but it sounds like an overkill to me.
INRIA packages do not have findlib support as far as I know. Perhaps they have
more time than I to handle installations in a conventional manner.
>>[...about the logic of META files...]
>
>But we cannot ask every pacvkage maintainer to provide this file, they don't
>know about it, it is heavy syntax and error prone (well when you add typos in
>it).
This is of course a problem. I still hope that other people adopt my system.
For the most important INRIA packages, findlib's configure script adds the
missing META file. Maybe you need a similar post-install script that adds
missing META files in the same way. (I have good experiences with generating
META by m4.)
>>
>> So it is not necessary to update a meta-information db. Just add a META file
>> for every package, and it will be found by findlib. Without findlib, the extra
>> file can be ignored.
>
>Ok, but is it not possible to generate this meta information directly with a
>simple script being invoked at install time ...
Simple answer: No, it is not possible. META contains the information
you typically find in _usage_ instructions, such as
"Programs that use the XXX library must be linked as follows: XXX". It's an
encoding of these instructions that are normally only available in English.
>>[...about $(CAMLLIB)/package-name...]
>>
>> However, I do not like this. CAMLLIB is already a quite large directory, and
>> this makes it difficult to survey. A separate directory containing all add-on
>> packages is simpler to handle, and easier to understand. I can do a
>> ls /directory and it lists all installed packages.
>
>what about a finlibtool -list or something such ?
This would be an alternative.
>> Unfortunately, the caml team has decided to continue the $(CAMLLIB)/package-name
>> pattern. In the upcoming 3.01 release the compiler understands
>> -I +package-name and internally translates this option to
>> -I (CAMLLIB)/package-name. What do you think about this?
>
>It is really a big plus in developpment when you don't do advanced stuff like
>you do.
To my mind, this sounds rather academic. The ideas in findlib result from
project experience; maybe it is a bit more work to install the packages but it
is a lot easier to use them. (Especially to tell other people how to use them.)
>i would have advocated for a direct search path from $(CMALLIB) without the
>need for the +package-name stuff.
>
>That said, mlgtk for example installed in $(CAMLLIB) directly.
>
>> (3.01 is not yet out. There is still the chance that they add a search path for
>> packages.)
>
>a search patch, something more than the -I stuff ...
>
>> Findlib has a redirection feature which is currently used for the official
>> packages, and for the core packages (from findlib's point of view, the
>> libraries str, unix etc. are also packages needing meta-information). For
>> example, for camltk I have in site-lib/camltk a META file (and nothing else)
>> which redirects the location of the package:
>
>why not put all meta files into /var/lib/ocaml/xxx.meta or somethign such.
You like centralized databases, don't you.
Currently, I draw the following conclusions from our discussion:
- findlib needs a configuration file specifying the search path and the default
installation directory
- the installation method needs a way to specify an alternate target directory
Furthermore, there is a problem with packages that do not support findlib in
their source distribution, e.g. the INRIA packages. My recommendation is to
add a post-install script that extracts the necessary data from somewhere and
generates META.
I don't see the problem resulting from a deferred installation of findlib.
Every package that wants to be findlib-compliant can install a META file for
itself, and if findlib is installed later it will find all that already
existing METAs. There is no way to generate META by a generic method for
debian packages that do not provide it.
Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann Telefon: +49 6151 997705 (privat)
Viktoriastr. 100
64293 Darmstadt EMail: gerd@gerd-stolpmann.de
Germany
----------------------------------------------------------------------------
Reply to: