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

[Michael Ekstrand <michael+ocaml@elehack.net>]

Sylvain Le Gall <sylvain@le-gall.net> writes:
> Using a simple wget/rsync (you can redevelop it in OCaml) is far
> more simple than to use a VCS.

Hear, hear.

I think that it's somewhat strange to incorporate the source for all
packages into one massive VCS, and it looks like that's what's been
proposed.

Forgive me if I'm rehashing things that have already been brought up,
but I think that some kind of hybrid thing is good, and that Sylvain
has some excellent points.  For the general case of package
management, you need 2 things, metadata and source, and those two
should probably not be managed together.  The Ports-like systems all
seem to do this well - you have a tree of metadata (usually managed
via some VCS [FreeBSD uses Perforce and CVS], but easily distributed
via rsync to end users).  Metadata references tarballs.  I don't see a
whole lot of merit for hooking into upstream VCS for the general case,
as most users will probably want to use released tarballs of
everything except the few modules they're working on.

Now, it makes a lot of sense to me to use a DVCS for managing the
metadata, but that's entirely orthogonal to the systems used for
managing sources.  The DVCS metadata has the benefit of allowing
developers to pull down a tree, version-control their changes as they
incorporate controls to build newer/CVS versions, and the resubmit
those to the master tree for distribution to users.  Administrators
can pull down a tree, version-control local adaptations (changing
compiler options or whatnot), and re-sync with upstream in a
controlled fashion.  Also, for this, providing the ability to pull
source from VCS would be a decent idea, so the developer can build on
their local system, but this is primarily for development purposes and
not for production or end-user distribution (in the general case).
This could possibly be implemented by hooks to generate tarballs from
the VCS -- yes, it has some build overhead, but it keeps the
developers honest by making the path of least resistance require that
their source stay in a quasi-releasable state.

Whether this metadata looks like Debian build files, or like
*BSD/Gentoo ports, or a tree of RPM SPEC files, doesn't much matter in
my mind.

To recap, my vision for this thing:
 - Tree of build control and dependency declaration files, managed
   with a DVCS, with end-user distribution (perhaps updated nightly
   from the VCS) via rsync.
 - Tarballs of upstream releases, published by upstream developers,
   and cached by the distribution project (i.e. a "distfiles"
   directory containing the sources for all software currently
   referenced by the tree, perhaps with old versions also).

Now, to test code against the tree, the developer checks out a local
copy of the metadata tree.  They then go to the control files for
their project, and modify them to say "get the source from over here"
(adjusting version numbers, controls, etc. as appropriate).  Then,
they build, and everything should work smoothly, with minimal hassle.

Of course, the CPAN-style proposal also sounds like a good idea.  I'm
just not so sure on this whole all-sources-in-one-tree thing - it
seems like a significant amount of wasted space and strangeness.

(Of course, if I'm misunderstanding what's being proposed, feel free
to correct me!)

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.