Re: [Caml-list] OCaml packaging problems

[Vitaly Lugovsky <vsl@ontil.ihep.su>]

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
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.

> 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.

> 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.

> 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
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.

> 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,
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.

> >  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.

> >  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
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?

> >  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.

> 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
remember all that Windows pain with DLLs?

> 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
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
until the clear library packaging approach is choosed. :(

-------------------
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