From: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
To: "Nicolas Pouillard" <nicolas.pouillard@gmail.com>
Cc: Berke Durak <berke.durak@exalead.com>, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Ports-like package management system
Date: Tue, 29 Jan 2008 20:13:40 +0100 [thread overview]
Message-ID: <B58792AD-ADDC-48E6-9C21-FA3F020C22A6@erratique.ch> (raw)
In-Reply-To: <1201629992-sup-8035@ausone.local>
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.
Best,
Daniel
next prev parent reply other threads:[~2008-01-29 19:13 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 10:56 Berke Durak
2008-01-29 11:12 ` [Caml-list] " David Teller
2008-01-29 13:11 ` Yaron Minsky
2008-01-29 14:04 ` Nicolas Pouillard
2008-01-29 17:35 ` Berke Durak
2008-01-29 18:02 ` Bünzli Daniel
2008-01-29 18:10 ` Paul Pelzl
2008-01-29 22:26 ` Paolo Donadeo
2008-01-30 1:55 ` Bünzli Daniel
2008-01-29 22:46 ` Paolo Donadeo
2008-01-29 13:47 ` Yaron Minsky
2008-01-29 14:04 ` Nicolas Pouillard
2008-01-29 16:00 ` Alain Frisch
2008-01-30 6:58 ` Yaron Minsky
2008-01-30 8:56 ` Nicolas Pouillard
2008-01-29 17:56 ` Bünzli Daniel
2008-01-29 18:17 ` Nicolas Pouillard
2008-01-29 19:13 ` Bünzli Daniel [this message]
2008-01-30 8:49 ` Nicolas Pouillard
2008-01-30 11:15 ` Bünzli Daniel
2008-01-30 11:52 ` Nicolas Pouillard
2008-01-29 18:47 ` Hezekiah M. Carty
2008-01-30 9:06 ` Sylvain Le Gall
2008-01-30 9:39 ` [Caml-list] " Berke Durak
2008-01-30 9:53 ` Sylvain Le Gall
2008-01-30 10:50 ` [Caml-list] " Nicolas Pouillard
2008-01-30 11:15 ` Bünzli Daniel
2008-01-30 11:54 ` Nicolas Pouillard
2008-01-30 13:58 ` Sylvain Le Gall
2008-01-30 14:08 ` [Caml-list] " Nicolas Pouillard
2008-01-30 11:15 ` Berke Durak
2008-01-30 11:47 ` Bünzli Daniel
2008-01-30 13:55 ` Sylvain Le Gall
2008-01-30 13:54 ` Sylvain Le Gall
2008-01-30 14:24 ` [Caml-list] " Berke Durak
2008-01-30 14:35 ` Sylvain Le Gall
2008-01-30 19:48 ` [Caml-list] " Bünzli Daniel
2008-01-30 18:12 ` Vlad Skvortsov
2008-01-30 16:32 ` Michael Ekstrand
2008-01-30 16:44 ` Sylvain Le Gall
2008-01-30 18:03 ` [Caml-list] " Nicolas Pouillard
2008-01-30 19:45 ` Olivier Andrieu
2008-01-30 19:53 ` Vlad Skvortsov
2008-01-30 10:45 ` Sylvain Le Gall
2008-01-30 9:51 ` [Caml-list] " Jon Harrop
2008-01-30 10:18 ` Sylvain Le Gall
2008-01-30 10:43 ` [Caml-list] " Jon Harrop
2008-01-30 12:00 ` Nicolas Pouillard
2008-01-30 13:25 ` Jon Harrop
2008-01-30 14:06 ` Nicolas Pouillard
2008-01-30 12:37 ` Pietro Abate
2008-01-30 13:26 ` Stefano Zacchiroli
2008-01-30 14:07 ` Gerd Stolpmann
2008-01-30 13:37 ` Stefano Zacchiroli
2008-01-30 15:12 ` Gerd Stolpmann
2008-01-31 9:02 ` Stefano Zacchiroli
2008-02-01 15:03 ` Gerd Stolpmann
2008-02-03 20:21 ` Stefano Zacchiroli
2008-02-04 3:40 ` Matthew Hannigan
2008-02-04 18:42 ` Nathaniel Gray
2008-01-30 17:42 ` David Allsopp
2008-01-30 14:13 ` Sylvain Le Gall
2008-01-30 20:22 ` [Caml-list] " Bünzli Daniel
2008-02-08 22:24 ` N. Owen Gunden
2008-01-30 15:15 ` Jon Harrop
2008-01-30 12:37 ` [Caml-list] " Berke Durak
2008-02-13 8:45 ` David Teller
2008-02-13 10:02 ` Sylvain Le Gall
2008-02-13 10:48 ` [Caml-list] " Berke Durak
2008-02-13 13:51 ` Sylvain Le Gall
2008-02-13 14:10 ` [Caml-list] " Richard Jones
2008-02-13 14:22 ` Sylvain Le Gall
2008-02-13 17:57 ` [Caml-list] " Richard Jones
2008-02-15 8:13 ` Maxence Guesdon
2008-02-15 9:47 ` Berke Durak
2008-02-15 10:24 ` Maxence Guesdon
2008-02-15 10:59 ` Stefano Zacchiroli
2008-02-15 15:45 ` Maxence Guesdon
2008-02-15 13:35 ` Ralph Douglass
2008-02-15 14:08 ` Christophe TROESTLER
2008-02-13 12:13 ` David Teller
2008-02-13 13:48 ` Sylvain Le Gall
2008-02-13 13:58 ` [Caml-list] " David Teller
2008-02-13 14:20 ` Sylvain Le Gall
2008-02-13 14:28 ` [Caml-list] " David Teller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B58792AD-ADDC-48E6-9C21-FA3F020C22A6@erratique.ch \
--to=daniel.buenzli@erratique.ch \
--cc=berke.durak@exalead.com \
--cc=caml-list@inria.fr \
--cc=nicolas.pouillard@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox