Re: debian packaging of findlib
On Mon, 19 Feb 2001, Sven LUTHER wrote:
>On Sun, Feb 18, 2001 at 06:58:52PM +0100, Gerd Stolpmann wrote:
>> On Sun, 18 Feb 2001, Sven LUTHER wrote:
>> >[...about the philosophy of debian standards...]
>> >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
>
>Err, no it don't work like that, he just see's : how there is already a debian
>package from this great new stuff, let's install it, he types apt-get install
>package-name, and automatically the pre-built package is donwloaded from one
>of the officials debian mirrors, where only dbeian developper have right to
>upload packages, together with all packages that are needed for it, and it get
>installed. No need of findlib or any other such stuff. He don't even need to
>know it is an ocaml package.
>
>In this world view, findlib will be usefull only for ocaml developper, the
>rest of the world wouldn't care less about it.
Well, I can accept this as your vision. However, please don't forget that there
are currently not so many ocaml applications, and in my opinion it is a nearer
goal to convince more developers of the advantages of ocaml. So I would
appreciate it if the debian ocaml package addresses the wishes of developers as
well.
>> 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
>
>no, they are binary packages, and as thus, the build process is done by the
>maintainer, and the auto-builder for the other supported architecture.
>
>> requires that findlib is already installed. For a purely binary package it
>> is not required.
>
>Well, it would be nice if that would not be a requirement. I guess it is
>possible (as you said, we only need to provide the meta package, or a quick
>way to generate one).
The idea of findlib is to enforce a certain directory layout, and if you
install a debian package, you can easily ensure that the structure follows the
needed layout (because you have packed it). The whole magic of
"ocamlfind install" is also to ensure that layout; actually it is only a cp
into the right directory, not more.
By the way, there is a findlib manual explaining all that step by step:
http://www.ocaml-programming.de/packages/documentation/findlib, or
in the distributed tarball.
>What we want do to find findlib, is that, for packages where only ocamlfind is
>available for install, they will build-depend on it, but on other packages,
>well upto now, it is not possible to use findlib with them. So it would be
>nice to have a small script that will generate the META information at package
>install time, so that a user relying on findlib for developpment can make good
>use of them. We don't want ot force every ocaml developper to use findlib.
For a simple package, META must look as follows:
version = "XXX"
description = "XXX"
requires = "P1 P2 ..."
archive(byte) = "lib.cma"
archive(native) = "lib.cmxa"
Maybe there are some heuristics to generate it. For example, you can look if
there is only one .cma/.cmxa archive, and put its name into the archive line.
For more than one archive it becomes difficult; maybe you can use them only
alternatively, or in certain combinations. There is no generic way to obtain or
even to guess that. - Perhaps you can extract the prerequisites from the debian
package infos. However, debian packages (as far as I understand) only include
build-time and not developer-usage-time dependencies. This can make a
difference, because it is possible that a package A needs another package B at
build-time only to extract the necessary modules and to put them into its own
archive. When the package is used to build some software C it is sufficient to
link with the library found in A (even worse, trying to link with B would cause
link conflicts).
I do not really know if a heuristics is possible that has some success. Perhaps
it is simpler to have a quick look at the sources and manually write these five
lines.
>> 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.
>
>Why not use the special place directly ?
I have quite good experience with installing META in the same directory as the
other files. First, it is clear that the META file found in some directory
describes the findlib package in the same directory. Second, the META file is
used as a tag that makes the directory a package directory (useful when
searching for package directories).
It is possible to store the META files in some other directory, provided that
every META file contains a "directory" directive pointing back to the original
directory. It is even possible to have both approaches at the same time. If you
really want it, I can implement it; this would make only a few lines of code.
>> 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.)
>
>Yes, that would be the ideal way, i don't know exactly what is needed, but i
>guess you can answer us on this.
In ocaml 3.00, it has become quite easy to generate these META files because
they are almost constant (that was not true in 2.04 because of the -ccopt/-cclib
options often containing paths), especially if you generate them for a certain
distribution. In the findlib sources, you can find (very simple) m4 scripts,
one for every package; look into the directory site-lib. The generated
"linkopts" lines are outdated in 3.00; most of the intelligence of the
configure script was necessary to determine these lines. Only very few
variables remain if you delete the superflous "linkopts" lines.
Of course, there are some more INRIA packages not yet handled; but this is
simply because I did not use them until now.
>> >>
>> >> 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.
>
>Err, how do you generate it then ?
For a _certain_ package I can generate them because I can transform the English
instructions into an algorithm. But there is no _generic_ solution for
arbitrary packages because I would need some intelligent algorithm
understanding the English text.
>> You like centralized databases, don't you.
>
>Well, everything belongs to it's right place. that is the advantage we have in
>a integrated system, that you can do things properly, without needing to make
>workaround because you don't control the layout of your whole system.
>
>that said, i was speaking about a directory which will contain all meta files,
>not a single meta file with all the data. A bit like the manpages are handled.
As already said: possible, but I wouldn't consider the other solution as
workaround.
>> - the installation method needs a way to specify an alternate target directory
>
>Yes, and ideally, a conventional install target, is it possible to
>'pre-process' the ocamlfind stuff, in a way similar to how the
>autmoake/autoconf stuff work ?
>
>You use it for out_of_cvs versions, but not in released packages.
I can add such conventional install targets when I update the packages from
time to time.
Preprocessor: You mean a mechanism that writes a Makefile maybe by using a tool
like findlib, and in the resulting Makefile there is no more findlib call?
I hoped to get around that... Maybe it's nice for you, but it destroys the
abstractions introduced by findlib.
>> 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.
>
>Yes, this would be nice, but i think it would be best if you did this, as you
>have the best knowledge of how things work in findlib, and may even change
>things in future releases.
For some INRIA packages (camltk, labltk, camlp4) the generator exists:
findlib's configure script. I would recommend to simply run it, and to look at
the result, and to change manually the things that went wrong (e.g. wrong path).
>Ok, so each package that want to support findlib has to provide the correct
>META file. mmm, ...
>
>Do you have already a public file descirbing the META syntax or somethign
>such, and explaining how to generate it ?
See above the link to the manual. I hope it's easy to understand.
>I guess that if the whole debina-ocaml stuff supported findlib directly, maybe
>it would gain widder acceptance, which would be good ofr you.
That would be fine.
Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann Telefon: +49 6151 997705 (privat)
Viktoriastr. 100
64293 Darmstadt EMail: gerd@gerd-stolpmann.de
Germany
----------------------------------------------------------------------------
Reply to: