Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: info@gerd-stolpmann.de
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Packaging OCaml for Linux
Date: Sun, 31 Oct 2004 21:00:05 +0900 (JST)	[thread overview]
Message-ID: <20041031.210005.48374762.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <1099079054.25474.76.camel@ice.gerd-stolpmann.de>

From: Gerd Stolpmann <info@gerd-stolpmann.de>

> > > 1) Which OCaml distribution should be the basis for the Linux package:
> > >    the basic distribution from INRIA, or GODI? Why do you think so?
> > 
> > GODI is probably difficult to make into a package: it is a package
> > manager itself.
> 
> I think this is straight-forward. After all, GODI just installs files,
> and the files can be repackaged with the package manager of the Linux
> distribution.
> 
> Of course, the user must not call the GODI build system manually after
> that (i.e. godi_console must no longer be used). When the Linux package
> manager is responsible for managing the packages, it must be avoided
> that it interfers with the GODI build system in an uncontrolled way,
> because GODI would replace files, and the Linux package manager is not
> informed. (And doing so is really hard, I think this is the difficulty
> Jacques Garrigue means.) 

There are two parts in GODI: the ability to compile ocaml related
software uniformly, and the ability to maintain a coherent state
considering their dependencies.
You can certainly exploit the first aspect from a packaging system,
but I don't see how you can use the second one, which is really where
GODI shines.

> But in general, stacking of package managers should work as long as
> there is a clear hierarchy, and one manager calls the other as
> subordinate tool (and no user takes the freedom to call the subordinate
> manager directly, breaking the hierarchy). 

But even calling GODI from the package manager should be able to
update other godi packages, no? How is the package manager going to
keep track of that?
Or is there already some support for that in GODI? If this is the
case, and GODI can call package manager commands to update the
database, the even calling GODI directly should be OK.

> > > 2) What about LablTk? Should it be included, excluded? Should I break it
> > >    into a separate package, as is often done with Python/Tkinter? Is
> > >    that even possible with OCaml?
> > 
> > You should be aware that ocamlbrowser (which is included in the
> > distribution) depends on LablTk. So if you remove labltk from the
> > package, default users will not get it.
> 
> On the other hand, there are users who need not ocamlbrowser, because
> they install O'Caml only because their favourite application happens to
> be written in O'Caml.

If they use binary packages, they don't need to install ocaml at all.
If they compile the application themselves, then it might be nice to
have a real ocaml installed. At least they won't have to wonder
afterwards why they don't have some utilities/libraries which are
supposed to be in the standard distribution.
(Again, I don't mean that it shouldn't be possible to disable some
libraries, particularly if you don't have X11 for instance, of if the
user knows exactly what he wants, but I don't see the point of
providing a partial system without warning.)

Jacques Garrigue


  reply	other threads:[~2004-10-31 12:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-28 20:40 Matt Gushee
2004-10-28 21:12 ` [Caml-list] " Olivier Andrieu
2004-10-29  0:51 ` Jacques Garrigue
2004-10-29 18:34   ` Blair Zajac
2004-10-29 19:52     ` Gerd Stolpmann
2004-10-29 19:44   ` Gerd Stolpmann
2004-10-31 12:00     ` Jacques Garrigue [this message]
2004-10-29  2:31 ` skaller

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=20041031.210005.48374762.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=info@gerd-stolpmann.de \
    /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