On 19 Feb 2015, at 17:05, Drup <[email protected]> wrote: > >> Out of curiosity, what was tedious to maintain there? >> >> One thing that's come up in both Mirage and XAPI is to have a script that >> 'splices' a released package from one remote to another. That would let us >> upload stable cuts to a working remote, and then move them over to >> opam-repository. Would that sort of thing help Ocsigen as well? > The opam ocsigen was never done for stable packages, opam-repository is > already there for that. We did it when eliom 4.0 was cooking, and the > previous eliom version of eliom was very old, so it was necessary even for > beginners to use the dev versions of all the packages. opam pin was not very > mature at the time. > > Now, with opam pin, we have opam files in each package repository, and we > would need a mostly-the-same but slightly-different set of opam files in the > opam repository. In practice, the opam repository was never updated and was > kept out of sync all the time, confusing everyone. > > Also, the need to use dev versions is far less important, since the released > versions are much closer to the dev versions. And with `--dev-version`, > pinning dev versions is really easy. > > Basically, it's a mix of inconvenience to maintain and lack of necessity. We > could probably have automate it (probably not completely, though), but in the > end, it's not really worth it.
Makes sense. The use of the remote is useful for stable packages when you need to 'gang schedule' a bunch of constraints and have a place to put them to test for breakage in the broader repository. I'm considering a model like this for the Core/Async package updates, since they typically break a few of the dependent packages in the OPAM repository after they are merged. It would be nice to have a consistent staging area where such errors could be sorted out ahead of merging into mainline. This problem may come up for Ocsigen as well as its number of libraries grows... -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
