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

[Berke Durak <berke.durak@exalead.com>]

Sylvain Le Gall a écrit :
> Please don't go into this. If you want to talk about PM, don't talk
> about VCS. My point is that if you want to build something that last you
> should keep focus on PM, which is not really bound to VCS (like content
> of files is not bound to filesystem). There is no best VCS for doing PM.
> We just should handle a way to :
> * let anyone use a different VCS
> * be able to download at least a version of each different packages

 > The most simple way to handle this, to my mind:
 > * distribute METADATA for packaging into ftp/http
 > * put a link to the VCS inside METADATA, to tell where you can find most
 >  recent one

We want to guarantee to the user that if she has installed Ocaml and the 
Ocaml package system, she will be able to use any component packaged in 
the system without having to install extra software.

The Ocaml pakcage system must therefore include as a prerequisite all 
the tools required for fetching data.  Hence if we want to use a VCS as 
part of the system, we must agree on one.

The VCS selected, if any, doesn't have to be the one the developers use, 
of course.  (But there exist many VCS-to-VCS bridges, so it's not really 
a problem.)

Speed and portability are however important.

Now why would we want to use a VCS?

* As a data storage and distribution mechanism
* For efficient updates
* For the ability to check out any revision

These functions could be emulated by having a directory with a lot of 
tarball snapshots and using wget.  This may work for passive use of the 
software but even for this limited use case, use of a VCS is much more 
useful - efficient updates, storage of all intermediate revisions, 
branches, and the possibility for the upstream author to directly work 
on that VCS.

But the aim of the Ocaml packaging system should be to foster 
cooperation among Ocaml developers.  That is why having a recommended 
VCS and a standardized build system (or at least set of build commands)
is important.

Assume we agree on a distributed VCS system S.  Most Ocaml software will 
be developed in its own S repository, hosted by the author.  So we will 
have programs P1, P2... with respective repositories S1, S2...

When you develop a program P you will have use programs P_{i1}, P_{i2}, 
... and thus have checkouts of repositories S_{i1}, S_{i2}, and so on. 
If you find a bug in P_{i1} you can directly edit the checked out 
version, recompile everything automatically by launching ocaml in P's 
directory and thus debug P_{i1}.  You can then locally commit your 
changes to P_{i1} and then easily push the patch or send the diff to the 
upstream author.

If we don't use a VCS, this becomes much more difficult and error-prone.

The increase in collaboration and productivity could be tremendous. 
This requires close integration of the build and repository system and 
agreement on a common VCS.

Now being able to use the software of your choice, plurality and 
multiplicity of solutions are all good, but in this particular case this 
hinders collaboration.

It's as if everyone was using a different language!

My intent was not to provoke VCS flame wars.  But I think agreeing on a 
VCS is important and a flame war or two is acceptable collateral damage 
in the process of selecting one.

Now of course I don't have a precise idea of what the Ocaml packaging 
system would be like, but I think the way to go is to :

   - Use a common distributed VCS system for storage and distribution of 
source code, with multiple repositories

   - A build system integrated with the package management system,

   - A package management system able to manage arbitrarily many 
versions or copies of the same software component, and compile any 
program using an arbitrary selection of the required versions,
-- 
Berke DURAK