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 NAA05793; Thu, 16 May 2002 13:20:08 +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 NAA05584 for ; Thu, 16 May 2002 13:20:06 +0200 (MET DST) Received: from mg.ihep.su (mg.ihep.su [194.190.161.38]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g4GBK5n06100 for ; Thu, 16 May 2002 13:20:05 +0200 (MET DST) Received: by mg.ihep.su (Postfix, from userid 65436) id 482A4B510F; Thu, 16 May 2002 15:20:04 +0400 (MSD) Received: from ontil.ihep.su (ontil.ihep.su [194.190.161.63]) by mg.ihep.su (Postfix) with ESMTP id C6E57B510C; Thu, 16 May 2002 15:20:02 +0400 (MSD) Received: from localhost (vsl@localhost) by ontil.ihep.su (8.11.6/8.11.6) with ESMTP id g4GAOni27321; Thu, 16 May 2002 14:24:50 +0400 Date: Thu, 16 May 2002 14:24:49 +0400 (MSD) From: Vitaly Lugovsky To: Sven Luther Cc: Subject: Re: [Caml-list] OCaml packaging problems In-Reply-To: <20020516071155.GA26745@lambda.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 16 May 2002, Sven Luther wrote: > > This concept looks like ls-R file in the teTeX distribution. And all > > packagers knows that this file is quite a problem. So, as for me, > > Would you elaborate more on said problems ? > It is a bit different though, altough i see why you say it is similar. In general, it's not a good idea to allow packages to modify file (not claimed as 'configuration' file) belonging to the other package. It's an installation sequence problem (it's not specified when you're installing a lot of packages in one time), it's a security problem (some may want to have a partical ownership/rights for such a file, which will be broken by that %post and %preun scripts). And, at last, it's not a modular approach. It's not a good idea to mix a configuration and a cache. > > I choosed the way suggested by Xavier Leroy - every .so file have > > simlink in %_libdir/ocaml/site-lib/, while the other library stuff > > located in the separate directory. > > Ok, if we go that way, it is okay by me, just a decision should be > taken, after a reasoned discussion, and after that we should stick to > it. Sure. But distribution packagers, like me, can't wait for such a decision. :( And, one more thing we have to keep in mind: it will be very nice to have a possibility to split ocaml libraries into runtime and development parts. Dynamic libraries belongs to the runtime part, and, then, should be handled in an OS native way. For Unices it's a libraries located in one big pile like /usr/lib/ > That said, i _don't like_ the symlink idea, symlink are a nice thing, > but mainly in this kind of cases are used when you don't have an > integrated distribution, and no packaging system, and many people also > claim that symlink can cause lot of problems. It is more a workaround > for case where you cannot do things properly. But this way is native for unices. It's generally used when you have different versions of libraries, and so on (see GNU libtool naming scheme for example). > > Then if we go that way (all stub libraries in one or two dirs), what > will happen, as far as debian and maybe other integrated distribution > are concerned, is that we will put the stub libraries in the directory > (/usr/lib/ocaml/shlibs or something such), and the rest of the stuff in > the subdirectory. There will be no symlink, and this needs a redesign of > the build process of all those libraries, an adaptation to things like > findlib and ocamlmakefile, and is quite big work, so best to do it for > after there is a final decision on the subject. We can't avoid that redesign. Especially if we really want to split runtime and development parts. This will become a pain when OCaml will be able to produce a real dynamic native libraries. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners