Version française
Home     About     Download     Resources     Contact us    
Browse thread
[OSR] Ports-like package management system
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
On Wednesday 30 January 2008 12:37:05 Pietro Abate wrote:
> I'd like to follow the lead from the idea above. I've the impression we
> are not converging. I think if we want to succeed in this packaging
> revolution we need to proceed is small steps.

Yes.

> The basic and foremost important requirement we have is to try to
> standardize the way ocaml libraries/applications are built.

... and installed!

> One of the 
> main problem package maintainers have is that everybody seems to write
> their own build system and to follow different rules in their projects.
> We have a plethora of building system, but in the end what we really
> need is an interface to use them. Using a simple makefile for example
> with make {opt,byte,install,clean} and to agree to what these rules do
> would be a huge step forward.

I would like to have core and enhanced OCaml distributions installed and 
simultaneously usable on my system with packages for each fetched, built and 
installed independently. This requires completely different compiled 
libraries (because the stdlibs will be different) and, therefore, different 
installed locations.

Perhaps the current system can already support this by giving the enhanced 
distro a version starting with "e":

  /usr/lib/ocaml/3.10.0
  /usr/lib/ocaml/e3.10.0

and so on. The OCaml compilers etc. should install to "ocamlopt-3.10.0" 
and "ocamlopt-e3.10.0" so the user can provide defaults, e.g. using Debian's 
alternatives.

The core and enhanced OCaml distributions could be separate Debian packages 
with libraries coming entirely from OCaml and nothing else coming from 
Debian.

I think this would solve a lot of headaches. This is orthogonal to VCS vs 
wget, of course.

> I'm not saying everybody must use make, 
> but that all projects should ship a makefile with these 4 rules.

I think that was actually an excellent idea. Can it get "ocamlc" 
and "ocamlopt" from environment variables and install to their default 
location with `ocamlc -where`?

> What is 
> then effectively used to build the package is not my problem (except for
> building dependencies with exotic tools). In the future we might think
> of proposing a standard building tool for everybody as ocamlbuild... but
> I think this is premature now.

Agreed.

> Ok, at this point we have the package, and we know how to build it. Next
> step is to have one place to upload all tarballs. Godi has its own
> repository, debian has its own repository on alioth. Here I'm thinking
> something like CPAN, with a light weight registration and upload
> mechanism based on pgp (Register, sign the package, upload the package).
> The infrastructure to build this kind of service is not rocket science.
> We could even imagine some king of validation process. This way all
> developer could just work as they do, using whatever vcs they like,
> adding just one simple step whan they want to release a new package into
> the wild. Dependencies could be addressed at this level or at the next.
> Anyway a complex project with many dependencies must find a way to
> resolve these dependencies somehow: either in their makefile (see
> require(http://bar.org/repository/) as above) or just by assuming that all
> dependencies are already satisfied and leave the burden to Package
> maintainers (as it is at the moment).
>
> >From this point on the sky. Debian, godi, fedora,... can just keep going
>
> as they do with their system but using a single upstream repository with
> standardized build system. People with other needs could use a system as
> describe above with ocamlbuild. In the future we can even think to some
> kind of convergence of different distributions to handle dependencies,
> versioning, etc ...

... licensing. The system should warn when licenses are broken. For example, I 
might like to release Smoke under the GPL for such a distribution and I'd 
like users to know when they're breaking the license agreement so they can 
buy the commercial license for Smoke (now only £199 ;-).

> In this way I tried to chance as small as possible of the current
> infrastructure, still trying to give people the possibility of easily
> recompiling their projects and all dependencies.
>
> Maybe this view it too naive, but it might be a good way to start.

I think these are really excellent ideas. I agree completely.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e