Re: [Caml-list] OCaml packaging problems

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

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