Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] CDK with Ocaml 3.06 (fwd)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-14 (22:45)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] CDK with Ocaml 3.06 (fwd)

Am 2002.10.14 23:07 schrieb(en) Sven LUTHER:
> On Mon, Oct 14, 2002 at 10:38:36PM +0200, Pierre Weis wrote:
> > [...]
> > > > 2) if we really need such a feature (for example just to have
> > > >    transparent access to packages between different linux distributions
> > > >    or between linux and windows and mac and ... worlds) who is
> > > >    responsible to keep an archive of available package gettable via
> > > >    ocamlfind or whatevere else?
> > > >    CPAN, APT, and other approaches work because someon set up an
> > > >    official or de-facto-official archive (Well, APT also support other
> > > >    repositories, but official one are the most used and trusted ...).
> > > 
> > > If this happens, maybe we can prevail on inria and the ocaml team to
> > > make disk space available to us ?
> > 
> > Yes, indeed. There is no problem of disk space here. The problem is to
> > grant access in a secure and reliable way.
> Well, debian uses a system with upload queues, and signed package witha
> strong web of trust between developpers who are allowed to upload
> packages. Sure we also have ssh access on most debian boxes, but this is
> not necessary for uploading.
> I am sure a scheme could be found for this kindof distribution, with an
> upload queue, where you could anonymously upload packages, which get
> scanned for secure signatures and uploaded onto the server, or something
> such. Maybe you could go without signatures even, since after all, there
> is nothing critical and absolutely needing root access in the ocaml
> packages.
> > > > 3) ocaml packages are usually distributed as source packages and we have
> > > >    not a standardized way to build and install them, the success of
> > > >    CPAN, APT, are due to the facts that _or_ the distribution is in
> > > >    binary form with standardadized file system sructure _or_ the
> > > >    distribution is in source form with standardized compilation and
> > > >    installation procedure
> > > 
> > > Yes, this is the problematic part.
> > 
> > I think we can set up a standardized compilation and installation
> > procedure (meaning a standard Makefile for libraries, based on the
> > configuration set up by the original Ocaml installation). We can start
> > with the Caml team maintained software (the ``bazaar'') and encourage
> > people to do the same for their own software by storing (and
> > distributing) it on our server. This could be a lot of book-keeping
> > but we could probably manage it...
> Well, the problem is more in the dependency handling, and could be worse
> if you maintain binary distribution, like you do for windows. But
> anyway, i don't believe you could really afford to do binary
> distribution for something else than windows or maybe macOSX.
> It is very difficult to do this nicely without an integrated
> distribution. Mmm, maybe it can be done, but would need lot of work, and
> anyway, inria don't has the vast multi arch build farm that debian has,
> so i don't know if it would be meaningfull.

Just a few phenomenons that are hard to tackle :

- Sometimes a Makefile is not enough, you need a configure script. Sometimes
  the configure script takes arguments (Where can certain C libraries be found?
  Which build variant is chosen?). These arguments cannot be found out
  automatically, they are beyond the intelligence of the configure script.

  So an automatic package fetcher would have to deal with this complication.
  Maybe it has to ask interactively.

- Sometimes a single distribution tarball creates several libraries.

- Sometimes there are alternative dependencies (you can choose whether you
  like package X or X' as antecendent)

- Sometimes there are files to install that are neither libraries nor
  documentation. You need interaction with the operating system's idea
  of installing files, and if possible, with its package manager.

- Authors usually cannot test source packages on lots of platforms. Problems
  range from /bin/sh incompatibilities to the Unix/Windows nightmare. Especially
  for the latter I really don't know how to cope with it, because porting
  Makefiles and scripts to Windows is time-intensive, and as a Unix fan
  I have the attitude "let the Windows users do it".

These are not exoctic complications that are rarely found, they are normal.
A reasonable source distribution format must deal with them, and there must
be people willing to create such enhanced source packages. I don't say
this is all impossible, but sure it is an ambitious project.

Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: