Browse thread
[OSR] Ports-like package management system
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Bünzli_Daniel <daniel.buenzli@e...> |
| Subject: | Re: [Caml-list] [OSR] Ports-like package management system |
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