caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
Cc: Pierre Weis <pierre.weis@inria.fr>, caml-list@inria.fr
Subject: Re: [Caml-list] CDK with Ocaml 3.06 (fwd)
Date: Tue, 15 Oct 2002 00:44:57 +0200	[thread overview]
Message-ID: <20021014224457.GM1002@ice.gerd-stolpmann.de> (raw)
In-Reply-To: <20021014210719.GA3682@iliana>; from luther@dpt-info.u-strasbg.fr on Mon, Okt 14, 2002 at 23:07:19 +0200


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
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------
-------------------
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


  reply	other threads:[~2002-10-14 22:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-14 16:42 Alain Frisch
2002-10-14 17:39 ` Stefano Zacchiroli
2002-10-14 17:59   ` Alain Frisch
2002-10-14 18:16   ` Sven LUTHER
2002-10-14 20:38     ` Pierre Weis
2002-10-14 21:07       ` Sven LUTHER
2002-10-14 22:44         ` Gerd Stolpmann [this message]
2002-10-15  4:42           ` Sven LUTHER
2002-10-15  4:53             ` Chris Hecker
2002-10-15  5:15               ` Sven LUTHER
2002-10-15  5:25                 ` Chris Hecker
2002-10-15  5:41                   ` Sven LUTHER
2002-10-15  6:34                     ` Chris Hecker
2002-10-15  5:02             ` Alessandro Baretta
2002-10-15  5:04               ` Chris Hecker
2002-10-15  5:08               ` Sven LUTHER
2002-10-17 17:57           ` Gleb N. Semenov
2002-10-15 11:21         ` Sign the packages (was Re: [Caml-list] CDK with Ocaml 3.06 (fwd)) Tim Freeman
2002-10-15 11:59           ` Sven Luther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021014224457.GM1002@ice.gerd-stolpmann.de \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=luther@dpt-info.u-strasbg.fr \
    --cc=pierre.weis@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).