From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA31924; Tue, 28 Aug 2001 02:27:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA31911 for ; Tue, 28 Aug 2001 02:27:56 +0200 (MET DST) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f7S0Rtn07915 for ; Tue, 28 Aug 2001 02:27:55 +0200 (MET DST) Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15bWjT-0005el-00; Tue, 28 Aug 2001 02:27:55 +0200 Received: from drms-3e364b6c.pool.mediaways.net ([62.54.75.108] helo=ice.gerd-stolpmann.de) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 15bWjS-0000zq-00; Tue, 28 Aug 2001 02:27:54 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id XAA27818; Mon, 27 Aug 2001 23:20:48 +0200 From: Gerd Stolpmann Reply-To: info@gerd-stolpmann.de Organization: privat To: Ian Zimmerman , caml-list@inria.fr (OCAML) Subject: Re: [Caml-list] Package dependencies [Was: standard regex package] Date: Mon, 27 Aug 2001 22:50:45 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <3750.998602056@saul.cis.upenn.edu> <20010824112654.C6986@dpt-info.u-strasbg.fr> <86d75hsdyn.fsf_-_@speakeasy.org> In-Reply-To: <86d75hsdyn.fsf_-_@speakeasy.org> MIME-Version: 1.0 Message-Id: <0108272320470B.02716@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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