Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: Bünzli_Daniel <daniel.buenzli@e...>
Subject: Re: [Caml-list] [OSR] Ports-like package management system

Le 29 janv. 08 à 19:17, Nicolas Pouillard a écrit :

> I  think  this  was  what  Berke  has in mind to. However the  
> repository still
> becomes very large even if there only a few files by package.

Then I don't understand anymore. So the system is still centralized in  
the sense that all port files are under the same vcs at some location.  
That is exactly the kind of thing I'd like to avoid.

If you don't have a centralized system, then managing your package's  
port file is at your discretion. The port file itself should describe  
the various versions it provides of the package, their dependencies  
and where you can find them.

>> For me this is too fine grained -- and this is also the reason why  
>> you
>> want to integrate a vcs to your system. I would like to be able to
>> specify a version that the developer of the package deemed stable
>> enough to distribute, not a random revision. I strongly think that
>> tarball releases are enough, if there are simple and efficient tools
>> to produce them. Going down to the revision is overkill.
> Perhaps  not so overkill for developers, if you've just patched a  
> project, you
> need   to  update  the  package  quickly  and  perhaps  not  want   
> to  have  a
> release/tarball  for  each  of  them.

Frankly this is not the average case, please try to solve the average  
case, not the baroque ones. If you need to follow a project at the  
patch level deal directly with the developer's repository. Browse the  
hump and try to think about which projects you'd follow at that level  
to use in your own projects - dealing with moving targets is annoying.

Besides having such a fine grain will bother both package users (up to  
which patch should I pull ?) and package developers (transient issues  
due to a user that pulled up to a given patch).

Another thing you may want to consider is that a "released" package  
may need less (build) dependencies than a direct pull from a  
repository (e.g. files generated using custom tools, etc.).

> I think that the upstream source can be
> either  a tarball URL or a VCS URL. For upstream sources one can  
> supports some
> VCSs (CVS, SVN, darcs, git, hg) since one only need to checkout.

A system can always be complexified. I'd rather have something simple  
that works. I strongly think the vcs should be kept outside the  
package management system.