Re: On module distribution

[Sylvain Le Gall <sylvain@le-gall.net>]

On 15-01-2008, Bünzli Daniel <daniel.buenzli@erratique.ch> 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