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=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 9468BBC69 for ; Tue, 15 Jan 2008 16:07:45 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFtbjEfAXQImh2dsb2JhbACQBwEBAQgKKZsI X-IronPort-AV: E=Sophos;i="4.24,287,1196636400"; d="scan'208";a="6064257" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2008 16:07:45 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0FF7aQp005497 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 15 Jan 2008 16:07:45 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB9bjEdQW+UCh2dsb2JhbACQBwEBAQgKKZsC X-IronPort-AV: E=Sophos;i="4.24,287,1196636400"; d="scan'208";a="7826775" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 15 Jan 2008 16:07:36 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JEnO2-0006Lm-Cd for caml-list@inria.fr; Tue, 15 Jan 2008 15:07:34 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 15:07:34 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 15:07:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: On module distribution Date: Tue, 15 Jan 2008 15:07:16 +0000 (UTC) Message-ID: References: <92920466-3BCE-4A9F-9742-3396B07006F7@erratique.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/0.9.8.1pl2 (Debian) Sender: news X-Miltered: at discorde with ID 478CCC38.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 buenzli:01 fwiw:01 node:01 node:01 dependencies:01 dependencies:01 ocaml:01 stubs:01 unification:01 wrote:01 semantic:02 modules:02 modules:02 hump:02 On 15-01-2008, Bünzli Daniel wrote: > A few month ago, after a discussion on cherry-picking modules in the > reins library I thought a little bit about devising a system to > facilitate module sharing. A system to simplify the tedious and > uninteresting actions needed to be able to use and publish modules. At > that time I started a design document for it, but as is expected in > such cases the effort didn't last long. > > However since people will be meeting in Paris in a few week to discuss > these things I thought there may be some ideas to take in this very > rough and incomplete draft of a system that I will never implement. So > FWIW here's a link [1] to this document. In summary the main ideas > were : > > 1. A decentralized system, anyone who can publish on a web server can > publish a package. A central authority is a bottleneck to publication. > Unfortunately, a decentralized system has also several drawbacks: * initial specification on how to be part of the decentralized system must be precise and complete enough to not need to update it -- decentralized system always need a clear "contract" to collaborate. This part is by far not tricky if you are not 100% sure of what you want to build and if you have never done it before (it is just like designing a network protocol). * you need to provide a backup foreach node of your system. Otherwise, every node will become a point of failure. This is critical: lets consider you have a package A that build depends on package B, C and D. With a centralized system you "download" point of failure is the central location, either it is up or down. With a decentralized approach your "download" point of failure will be the location of A, B, C and D. You have to find a way to circumvent this problem... * automatic build and different checkup are more easily done in a central repository (because everything is at the same place) * hijack of modules is more easily done in a central repository. This point is important because, OSS developper tends to be Missing In Action. * ... In fact, Debian user reading this will see that i am having the same sort of arguments that Debian has concerning the other distributions. Debian has developped a very centric repository for all its packages which other Linux distribution have not done. This tends to lead to have more control on the QA of everything. Which is better to my mind. > 2. Use atom feeds [2] as the distribution medium. Atom feeds contain > all the semantic information (authors, contributors, entries, rights, > link to enclosure, labels etc.) needed to represent a package and its > versions with release notes. Shortly a package is a feed, a version is > an entry with an enclosure link to an archive. The only extensions > needed (Atom allows this via xml name spaces) are new link attributes > to describe version dependencies. Packages as feeds allow to follow > their evolution with a plain newsfeed reader (which would also > facilitates the maintenance of repositories like the hump). To avoid > angle brackets, package feeds are generated from a tagged plain text > README file. > You should have a look to DOAP http://usefulinc.com/doap/ > 3. Manage packages per project (vs. per machine) to make project > dependencies explicit. Thus a single command can install you the > (OCaml + C stubs only) dependencies of your project on a fresh system. > If your project is a package itself, it facilitates its packaging . > I don't agree project and package are not the same thing. You should take into consideration that different distribution have different packaging policy. Trying to have the same packaging policy for every distribution is not feasable (well in fact it is possible but it is a very long term wokr -- something like the Grand Unification Theory). Regards, Sylvain Le Gall