Re: [Caml-list] Package dependencies [Was: standard regex package]

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Mon, 27 Aug 2001, Ian Zimmerman wrote:
>Miles> One danger in developing such a system is that you'll wind up duplicating the
>Miles> rather extensive functionality of existing package management systems.  RPM and
>Miles> DEB both handle these kinds of dependencies and are fairly complex systems for
>Miles> it.  CPAN has its shortcomings, but it also works suprisingly well most of the
>Miles> time.  I think you should at least consider taking a "worse-is-better" approach
>Miles> and build something that works and leave the delicate dependency management to
>Miles> the distribution packagers.
>
>Gerd> As far as I know, RPM/DEP focus on binary installations, and source packages
>Gerd> exist only to conveniently make binary packages. This means: Someone already
>Gerd> has reviewed the package and decided which versions to take.
>
>Sven> debian package include source dependencies, and you are true, it is the work
>Sven> of the package maintainer to provide those, aided by the numerous bug reports
>Sven> we get from the porters if the build dependencies are bad.
>
>Sven> That said, normally each package has listed in it's INSTALL/README the
>Sven> dependencies, though in an informal way.
>
>Sven> Maybe a kind of more formal dependency listing would be nice, which would be
>Sven> shared by all ocaml related sources, and may then be filled in the
>Sven> corresponding debian/rpm control files.
>
>The good thing about CPAN the module, and really the whole Perl build
>and install scheme, when it works, is precisely that it eases
>installation of tarballs [1] _which are not (yet) available_ in the
>native OS binary form; and it does this in a way that doesn't conflict
>with the OS installation.  That is, the distinction it makes between
>INSTALLPRIVLIB and INSTALLSITELIB.
>
>I believe this point is really fudamental to the Perl scheme, and is
>really what people mean when they use the term "CPAN" in this thread.
>To behave like that, yes we do need formal dependencies in the
>tarballs, completely independent of the dependencies an OS packager
>might add at the time of creating a binary package, and exploited in a
>uniform way by the tarball installation process (even if it is only
>for a check target, as Perl does it).

Yes, there is a difference between (1) the dependencies on the level of a
progamming environment and (2) the dependencies on the system level. For
example, the binary may use a system library, and this dependency is important
for (2) but not for (1) because it's outside the scope of the programming
environment. For a CPAN-like installer only (1) is of interest, but of
course, knowing (1) is very helpful to describe (2).

>I think the present findlib already does this, when configured
>properly; let's keep this functionality whichever way Ocaml
>build/install is eventually implemented.

findlib supports as many installation locations as you want, so you can easily
implement the difference between INSTALLPRIVLIB and INSTALLSITELIB. It is
thought as a tool to manage add-ons to the core O'Caml installation. At the
beginning, it supported only one directory (=INSTALLSITELIB), but after the
Debian people persuaded me several directories are allowed. Debian needs this
because there is one location where the OS packager installs and one location
where the user adds packages (seems to be a common requirement).

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr