From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 81E9FBC6D for ; Wed, 30 Jan 2008 16:21:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACUloEfAXQInh2dsb2JhbACCNo1xAQEBCAopgRSeIA X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="21982900" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 16:21:14 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0UFLDfY002926 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 16:21:13 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHQkoEfUnw7Wi2dsb2JhbACCNo1xAQEBCAQGBwgagRSeJg X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="8541360" Received: from ptb-relay03.plus.net ([212.159.14.214]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 16:21:12 +0100 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay03.plus.net with esmtp (Exim) id 1JKEkP-0008BH-4E; Wed, 30 Jan 2008 15:21:09 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: Pietro Abate , caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system Date: Wed, 30 Jan 2008 15:15:54 +0000 User-Agent: KMail/1.9.7 References: <479F0664.2070706@exalead.com> <20080130123705.GA21900@pulp.rsise.anu.edu.au> In-Reply-To: <20080130123705.GA21900@pulp.rsise.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801301515.54840.jon@ffconsultancy.com> X-Plusnet-Relay: bbd09a9235d8993f54c18aa488c65660 X-Miltered: at concorde with ID 47A095E9.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 makefile:01 byte:01 ocaml:01 distro:01 usr:01 lib:01 usr:01 lib:01 defaults:01 debian's:01 orthogonal:01 wget:01 makefile:01 ocamlc:01 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. =2E.. and installed! > One of the=20 > 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=20 simultaneously usable on my system with packages for each fetched, built an= d=20 installed independently. This requires completely different compiled=20 libraries (because the stdlibs will be different) and, therefore, different= =20 installed locations. Perhaps the current system can already support this by giving the enhanced= =20 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"=20 and "ocamlopt-e3.10.0" so the user can provide defaults, e.g. using Debian'= s=20 alternatives. The core and enhanced OCaml distributions could be separate Debian packages= =20 with libraries coming entirely from OCaml and nothing else coming from=20 Debian. I think this would solve a lot of headaches. This is orthogonal to VCS vs=20 wget, of course. > I'm not saying everybody must use make,=20 > but that all projects should ship a makefile with these 4 rules. I think that was actually an excellent idea. Can it get "ocamlc"=20 and "ocamlopt" from environment variables and install to their default=20 location with `ocamlc -where`? > What is=20 > 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 ... =2E.. licensing. The system should warn when licenses are broken. For examp= le, I=20 might like to release Smoke under the GPL for such a distribution and I'd=20 like users to know when they're breaking the license agreement so they can= =20 buy the commercial license for Smoke (now only =A3199 ;-). > 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. =2D-=20 Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e