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 VAA17453; Fri, 17 May 2002 21:37:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA17820 for caml-list@pauillac.inria.fr; Fri, 17 May 2002 21:37:19 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA14056 for ; Fri, 17 May 2002 17:59:24 +0200 (MET DST) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.44.193]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4HFxNf01504 for ; Fri, 17 May 2002 17:59:23 +0200 (MET DST) Received: from lambda.u-strasbg.fr (lambda.u-strasbg.fr [130.79.90.63]) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id RAA07298; Fri, 17 May 2002 17:57:48 +0200 Received: from luther by lambda.u-strasbg.fr with local (Exim 3.35 #1 (Debian)) id 178kEC-0008P7-00; Fri, 17 May 2002 18:05:12 +0200 Date: Fri, 17 May 2002 18:05:12 +0200 To: Vitaly Lugovsky Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml packaging problems Message-ID: <20020517160512.GA32290@lambda.u-strasbg.fr> References: <20020516071155.GA26745@lambda.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Sven Luther Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, May 16, 2002 at 02:24:49PM +0400, Vitaly Lugovsky wrote: > 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. Mmm, will look into it, so you are saying to me that there could be problem when multiple users are running ocaml-ldconf at the same time ? I don't really think that is so, but i will look more into it. 1) for package installs, dpkg ensures that only one dpkg is running at any time and that there is only one package being configured at the same time. 2) you need to be root to run ocaml-ldconf, so i think, security wise, there are a lot more thing to worry about if it is not you that have control on things, and if you do, i suppose you would not install two libraries at the same time ? But then, maybe i am not understanding you right, or you are speaking about a user modifiable config file ? > > > 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. :( Well, not sure, we decided on a course back then in january, and implemented it, now it turns out that we should have taken a different approach (since Xavier suggests it). Ideally there would be a strong policy document on such things. > 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 Ok, we have done that for debian, there is a libzip-ocaml package for example, that contains only the dll, and there is a libzip-ocaml-dev package that contains the rest of it, provides camlzip for backward compatibility and is built from the same source. No major problem here (apart from a long flamewart on the choosing of the name scheme). > 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/ Not sure if this zould be the real solution, since the dlls are handled in a something different way than normal unix C libs. (well in the way ocamlc and ocamlrun uses them maybe ?) > > 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). Ocaml doesbn't support versioning anyway, and there is no real need for it. And even if it is used, it can cause also a lot of trouble, so if you don't need it, better avoid it. > > 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. Yes, the more reason that a firm and concerted decision is taken, and then that we don't stray from it. BTW, what distribution do you represent and how many ocaml packages and libs do you maintain ? Friendly, Sven Luther > > ------------------- 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