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: 2008-01-30 (18:04)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
Excerpts from Michael Ekstrand's message of Wed Jan 30 17:32:20 +0100 2008:
> Sylvain Le Gall <> 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.

That's  what  I  have  in  mind,  but I think that Berke had the whole tree of
sources idea in mind.

But  what's  happen  when  you  want  to  improve  on  some  external package.
Generally  ports  like  systems  have  a  directory  where  they store patches
against  upstream. This kind of system is perhaps not the best one when you've
made a non trivial change on the upstream package.

However  you  can  point  the  URL  field  of the control file to your locally
hacked version of the upstream package.

Example, instead of:

$ cd dev-ml/libfoo
# make the patch
$ diff -u ... ... > files/libfoo-4.5_with_feature_bar.patch
# create a new control file, for this new version
$ cp libfoo-4.5.opkg libfoo-4.5_with_feature_bar.opkg
# add the patch to the list of patches in the .opkg

Rather do:

$ cd dev-ml/libfoo
$ cp libfoo-4.5.opkg libfoo-4.5_with_feature_bar.opkg
# replace the URL field in libfoo-4.5_with_feature_bar.opk
# by URL:

Nicolas Pouillard aka Ertai