Re: [Caml-list] [OSR] Ports-like package management system

["Nicolas Pouillard" <nicolas.pouillard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

Excerpts from daniel.buenzli's message of Tue Jan 29 20:13:40 +0100 2008:
> 
> 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.

You  have a local branch of the whole port hierarchy, that's why we're talking
about DVCS.

> >> 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).

That's  not  a  baroque  case,  I  mean  if  you are responsible of libFoo and
progBar,  you  perhaps  want to quickly package progBar using the last version
of libFoo.

[...]

> > 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.

I also would like to keep things simple...

-- 
Nicolas Pouillard aka Ertai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 186 bytes --]