Re: [Caml-list] OCaml packaging problems

[Sven Luther <luther@lambda.u-strasbg.fr>]

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