Re: debian packaging of findlib
On Mon, Feb 19, 2001 at 08:21:58PM +0100, Gerd Stolpmann wrote:
>
> 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.
Yes, but you are only speaking of the developpers using findlib, the one who
don't use couldn't care less, i think, and would perceive it as a nuissance
having to add a site-lib directory, or having to modify makefiles to get ride
of ocamlfind.
And there are commonly used ocaml packages in debian. Maybe mldvi is one such,
and i got a report for MMM which was from someone using it regularly, but
not knowing about ocaml.
> 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
Yes, that's the idea. but then you have said there is not a lot of stuff done
there, so for the install, it is easy to do it by hand (err, by traditional
makefile rules).
> "ocamlfind install" is also to ensure that layout; actually it is only a cp
> into the right directory, not more.
you don't even check that the META file is there, or copy it to the right dir
?
BTW, i have seen that in the packages you do :
$(OCAMLFIND) install stuff ...
what would have been nice, is that ocamlfind would have been compatible with
install at command line level, this way, you just set the OCAMLFIND variable
to empty, and install is used, ... mmm, not possible, you don't have a target
directory, isn't it ?
then what about :
$(OCAMLFIND) install stuff to install ... $(DESTDIR)
and putting DESTDIR to empty in the findlib install, and to the installdir in
the non-findlib install ?
> 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.
Ok, will look at it, is it only text, html, or something printable.
> version = "XXX"
> description = "XXX"
> requires = "P1 P2 ..."
> archive(byte) = "lib.cma"
> archive(native) = "lib.cmxa"
and the debian control file looks like :
Source: lablgtk
Section: devel
Priority: optional
Maintainer: Sven LUTHER <luther@debian.org>
Standards-Version: 3.1.1
Package: lablgtk
Architecture: any
Depends: ocaml (>=3.00), lablgl, ${shlibs:Depends}
Description: Ocaml bindings to Gtk+
lablgtk is another set of bindings for gtk+ and ocaml. It includes support
for gtkglarea and OpenGL bindings.
so you see almost everything is in there already, except the list of included
libraries, but these, i guess you get from the content file.
(note, the build-depends are missing from this file.)
> 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
No generic way to obtain it ? do you mean just listing all included .cma and
.cmxa is not enough ?
> package infos. However, debian packages (as far as I understand) only include
> build-time and not developer-usage-time dependencies. This can make a
no, the debian packages include build-dependencies, for building the package,
but this is something new.
The classic dependencies, are useage time one (a package that is not useable
when all dependencies are met is broken).
example is :
libgtk1.2-dev depends on : libgtk1.2, libglib1.2, libglib1.2-dev.
there is also other more advanced kind of stuff, like suggests, provide and
conflicts.
The first onelist a list of packages that are not absolutely needed, but would
be nice to have (like the doc packages). provide is when a package provides
the functionality of some other package or a virtual package. conflicts is
when you have cannot install this package together with some other.
> 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
Yes, this is build-dependencies, but then it is not nice stuff, since then you
end having the same thing installed 2 times, if you have both A dn B installed
at the same time. But then, i guess until ocaml supports dynamic links, it
will not be possible to do it differently.
> 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).
Yes, because you are including the same module 2 time, i undertsand that. This
would not be needed if you had dynamic links, and/or are able to add the
library name to the path of the modules.
> 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.
I see, mmm, are there lot of packages which do this kind of dirty trick ?
> 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).
Ok, i see, but in the long term aim of all packages supporting findlib, and
that all packages register themself to findlib during installation, this is
not needed.
> 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.
nice would be to have the centralized approach for the official debian
packages, and the META in directory approach in the user added modules in
/usr/local or $HOME.
But that said, i am only stating what would be very nice to have in a almost
perfect debian installation of findlib. i don't want you to devote time to it
if you don't feel like it, or something such, please don't take it bad ...
> >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
Yes, that is a nice feature too ...
> 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.
Ok, will look ...
> Of course, there are some more INRIA packages not yet handled; but this is
> simply because I did not use them until now.
Do you think that eventually every package would be handled by findlib ?
> instructions into an algorithm. But there is no _generic_ solution for
> arbitrary packages because I would need some intelligent algorithm
> understanding the English text.
I see ...
So you don't generate them with ocamlfind ?
> >> 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.
:)))
ok, don't, see above for more on this.
> >> - 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.
Err, when you use automake/autoconfig (i guess you are familiar with it) you
have a Makefile.in or somethign such, which get's pre-prossesed to something
that don't need these tools, the same goes with configure.in.
I think in our case, this would be more difficult to handle, but that was my
idea. You still keep the ocamlfind one around, or even you just reuse the same
Makefile, just expanding (in a second target) he findlib specific stuff.
Don't know if it is the best solution though.
> 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).
It is in the findlib package ?
> >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.
Will look at it.
> >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.
:)))
Again, i hope you don't take all my 'exigences' badly, nor for more than what
they are, ...
Friendly,
Sven Luther
Reply to: