[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Versioning OCaml in Debian [Was: Re: Buglet in ocaml-ldconf]



On Wed, May 29, 2002 at 03:40:56PM +0200, Denis Barbier wrote:
> On Wed, May 29, 2002 at 02:13:08PM +0200, Stefano Zacchiroli wrote:
> > On Wed, May 29, 2002 at 10:48:52AM +0200, Sven Luther wrote:
> > > This is not only something which makes ourt life (as developper) easier,
> > 
> > I think that we always agree on this.
> > The last mails we received from Denia are about versioning _third_part_
> > libraries, not debian ones (even if I still miss how this can be
> > done...).
> 
> Yes.
> 
> > > Finally, what is the point of this ? It is to keep multiple versions of
> > > libraries around,
> 
> The reason why I am advocating for /usr/local/lib/ocaml/3.04/ is to help
> admins which have to manage ocaml programs without knowing any single
> ocaml command.
> Again suppose he upgrades to ocaml-3.05, if something breaks weeks later
> he will be unable to determine which modules he forgot to compile against
> this new version, and he certainly won't find ocaml delightful.

Ok, nice argument ...

(but then, you have to guarantee that the new ocaml 3.05 don't search in
the 3.04 directories ...)

> [...]
> > With perl things are easier because every perl module install itself
> > using the same tools, we can't solve this problem until we have a
> > widespread tool for ocaml library distribution.
> > IMO this tools exists and is findlib we can help its spreading adopting
> > it as a debian default tool.
> 
> IMO what makes Perl much more user-friendly is that an admin does not have
> to know any command, he runs
>     perl Makefile.PL
>     make
>     make install
> (because he is told to do so by reading the README/INSTALL files) and
> that's all.

Same with ocaml package (well mostly), but then upstream developper will
use ocamlc -where to find where to put their libs, and put dll.so
containing directories in 'ocamlc -where'/ld.conf, which will be
overwritten by ocaml-ldconf.

> But I agree with you that having a standardized tool is a valuable first
> step towards ease of use.

More than a standardized tool, you need a standard policy on what goes
where. That said, sure, a standard tool is a good way of forcing such
policy.

The main problem is that that is something we need to discuss with
upstream, if not, nothing we do may really help here.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: