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 WAA12076; Thu, 23 May 2002 22:52:24 +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 WAA12050 for caml-list@pauillac.inria.fr; Thu, 23 May 2002 22:52:24 +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 VAA25815 for ; Tue, 21 May 2002 21:47:17 +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 g4LJlGX23738 for ; Tue, 21 May 2002 21:47:16 +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 VAA28302; Tue, 21 May 2002 21:47:09 +0200 Received: from luther by lambda.u-strasbg.fr with local (Exim 3.35 #1 (Debian)) id 17AFic-0004JR-00; Tue, 21 May 2002 21:54:50 +0200 Date: Tue, 21 May 2002 21:54:50 +0200 To: Vitaly Lugovsky Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml packaging problems Message-ID: <20020521195450.GA16522@lambda.u-strasbg.fr> References: <20020517160512.GA32290@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 Fri, May 17, 2002 at 11:31:37PM +0400, Vitaly Lugovsky wrote: > On Fri, 17 May 2002, Sven Luther wrote: > > > > 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 ? > > No. First problem is that package could be installed BEFORE the package This should not be hapenning, it probably is a bug in your package handler. Not sure though. What can happen is that both package are installed first, and then only configured, altough this late one will probably still be done in the dependency order. > it depends on, and, so, the file will not be updated. I don't know > is it apt-rpm bug or a general rpm feature, but I've noticed this behavior > a few times. And another one problem is that update script must be started > by the configuration file owner, which is a potential security hole. Well, it mostly is run by root, and so i guess this is a problem when you don't trust the packager. This is where debian's large web of truce and big number of packaged programs help a lot :))) > > I don't really think that is so, but i will look more into it. > > And, sure, there could be some problems with blocking. But I did not > considered this yet. Mmm, ... > > 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. > > And the same for rpm. But we may have a local packages as well, installed > without packaging system. It's a pain with only one global configuration > file. Well, not really, since upto now, they were handled in a separate file (/etc/ocaml/ld.conf) and even if you install them at the same time as you upgrade the system, it will only be broken until you next upgrade an ocaml package (and even then, its your own fault for messing things up). > > > 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 ? > > Sure. But we have only one configuration file, not a list of files with > different permissions and priorities. And so, localy installed libraries Mmm, we have two for debian, /etc/ocaml/ld.conf for the locally installed files, and /var/lib/ocaml/ld.conf for the dpkg handled ones. The first one will never be touched by ocmal-ldconf, and so there is no big risk about it. The only problem i have right now, is that locally installed files want to write to /usr/lib/ocaml/ld.conf, which is overwritten by a next run to ocaml-ldconf, i will be changing this in the next release of an ocaml debian package. There are two ways of doing this, making /usr/lib/ocaml/ld.conf readonly, so people running local installs will read it, and patching ocaml so it uses a /usr/lib/ocaml/debina_ld.conf or something such, and have /usr/lib/ocaml/ld.conf be a symlink to /etc/ocaml/ld.conf (which is a much more appropriate choice for this kind of thing, and policy compliant to boost. It would be nice if ocaml 3.05 would allow an easy configuration of the position of this file, as well as a option to ocaml that give this path back, in order for install systems to cope with non standard places. > goes there as well. And, again, we must install the package owning that > configuration file while we only want to use some applications and runtime > libraries used by them, which is not a good approach. Yes, maybe it would be ok to consider ta ~/.ocaml/ld.conf file ? > > But then, maybe i am not understanding you right, or you are speaking > > about a user modifiable config file ? > > Since we have only one config file, without local and per-user modules, Yes, i understand, we have two, so the problem is not so big, altough there are other problems, like the ones mentioned above, and the fact that you have to run ocaml-ldconf after modifying the local ld.conf databas (like it is done for the C /etc/ld.conf). If ocaml-ldconf was part of the upstream ocaml, it would make things easier. > this one should be user-modifiable. Or we have to invent a more modular > and secure approach. As well as I'm dreaming about having alternative > locations of texmf tree with their own ls-R configs. Mmm, my understanding was that users should use some other kind of trick for playing with dlls, not the ld.conf ones, especially if he is not root, unless it is a local ocaml install that is. > > > 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. > > Sure. But this policy must be secure and flexible enough not to conflict > with partial distributions policies. huh ??? What parital distributions policies are you speaking about ? > > > 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). > > May be there's no problem, but how do you handle dll paths without > that config file belonging to ocaml package? I can't check out Debian There is a ocaml-base package, which has only the dlls of the ocaml core distribution, the ld.conf files (mmm, maybe not even them) and the ocaml-ldconf executable. Each ocaml related package which has dlls is calling at postinst and prerm the ocaml-ldconf file, which adds or removes a path/package line in the /var/lib/ocaml/ld.conf file, and then regenerates the /usr/lib/ocaml/ld.conf file from this file and the /etc/ocaml/ld.conf one. If one of these files does not exist yet, they get created by the ocaml-ldconf program. I don't remember out of hand, but i guess they are also marked as conffiles, at least the /etc/ocaml/ld.conf one is. > approach now due to the problems with internet connection :( :))) > > > > 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 ?) > > I can't see the difference. Can you explain it? Well, they are only used by ocamlrun and ocamlc and co, not by any external program. > > > > 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. > > As well as C. Version is just a part of the library name. So, we can > have different versions of the library in the same directory, with > different applications linked with all that versions without conflicts. > It's not a language-specific matter at all. Well, previous discution here had me convinced that versioning would involve non trivial type checking for incompatible module interfaces or something such (not the best explanation, so please look at that huge thread youself). The basic idea was that if you were going to do versioning, let's do it right, and not like it is done in C, and that doing it right is not an easy thing. > > And even if it is used, it can cause also a lot of trouble, so if you > > don't need it, better avoid it. > > It can't cause troubles. But the lack of this feature can. Don't you Sure, just imagine someone changes the interface without bumping the major version number, or that some of the symlinks got broken badly by a mix of hand and automated isntalls (not to speak about a broken package), and things will break some, don't you think. > remember all that Windows pain with DLLs? No, i never run windows if i can avoid it :))) > > BTW, what distribution do you represent and how many ocaml packages and > > libs do you maintain ? > > ALT Linux. It's a russian distribution formerly based on Mandrake, but Ok, i didn't know of you. Please feel free to subscribe to the debian-ocaml-maint mailing list, where we discuss things related to package maintenance of ocaml related packages. It is debian specific, but many things may not be, and i think we will be happy to have you there (well as the list moderator, i am inviting and welcoming you). > evolved then to the completely new base. It's working over apt-rpm port. > Now I packaged some findlib-based libs, lablGL, lablgtk, camlimages, > camltk, and so on - the things I'm using myself. And I can't move forward Same for me, (altough i don't do findlib myself, i never use it). BTW, did you resolve the problem of camltk not being dll ready ? > until the clear library packaging approach is choosed. :( Well, ok, i see your point. We decided to choose a solution that worked ok for us, and i did implement it. Now, it appears upstream as choosen another approach, but debian woody will chip (any day now) with the current situation of using two databases and ocaml-ldconf. 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