<div dir="ltr">Another possible solution is to have the repository format include its version number somewhere. Then make opam always check the version number and give a useful message if it doesn't know how to deal with the repo version. The message is "sorry, if you want to use <a href="http://opam.ocaml.org">opam.ocaml.org</a> (or whichever repo it is), then you have to upgrade opam".<div>
<br></div><div>This doesn't provide as smooth of an upgrade path as your proposal, but it seems easier to implement. Automatically updating opam and updating the repos a user has configured is likely to be buggy. Also, it is possible that a single version of opam can work with multiple repo versions.</div>
<div><br></div><div>In all cases, it should be considered that <a href="https://opam.ocaml.org">https://opam.ocaml.org</a> must remain the main repo URL. It is the nice URL and we don't want to have the next repo be at <a href="https://opam2.ocaml.org">https://opam2.ocaml.org</a>.</div>
<div><br></div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 12:28 PM, Roberto Di Cosmo <span dir="ltr"><<a href="mailto:roberto@dicosmo.org" target="_blank">roberto@dicosmo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[I am moving this discussion away from the BTS and into<br>
the mailing list, as the issues raised here are of<br>
general relevance for the future of Opam, and must<br>
not be lost in the middle of other comments; see<br>
<a href="https://github.com/ocaml/opam/pull/1149" target="_blank">https://github.com/ocaml/opam/pull/1149</a> for the original<br>
discussion<br>
--<br>
Roberto<br>
]<br>
<br>
The original issue: what build system should we use to build opam?<br>
Should we cook up an ad-hoc Makefile, use a patched ocamlbuild,<br>
or use OCamlMakefile, or use ocp-build? Is it evil to embark<br>
a build system in the package manager source code?<br>
<br>
My quick view of these issues:<br>
<br>
1) choice of the build system<br>
<br>
we are already plagued with multiple build systems, and one of the reason<br>
of opam's success is that it allows every package author the freedom to use<br>
the one he/she prefers/ is more comfortable with.<br>
Opam is no exception, and opam developers must be able to pick the build system<br>
they prefer, so I would say, it's their decision to make<br>
<br>
2) embarking a full build system into the source tree of a package<br>
<br>
in general I would find this a very bad idea: one should have a separate<br>
package for the build system, and have it installed before building anything else.<br>
<br>
Now, what sets opam apart from other OCaml components is the fact that it is<br>
the *basic* building block for all the other packages in the repository, and<br>
without a running opam, there is no way to install any other package; this<br>
is a bootstrap issue, and that's why, for example, opam embarks in src_ext<br>
the full source of the dose and libcudf libraries, instead of linking to<br>
the packages for dose and libcudf (that do exist in the repository); so<br>
in this particular case *only* I personally would not be shocked to see<br>
some extra stuff in the src_ext directory (especially considering that<br>
all this will need to work on multiple platforms)<br>
<br>
3) how do we update opam?<br>
<br>
Now, for another important issue, related to the special status of opam<br>
as *the* package manager, and how we should manage it (hence the title<br>
of this message).<br>
<br>
I am a bit unhappy with the current state of affairs, where new<br>
versions of opam appear with incompatible changes in the repository format,<br>
hence different versions of the repositories: people using old versions<br>
of opam get lost in a limbo-like repository with non updated packages<br>
until they realise they need to recompile a new version of opam<br>
to see the light again.<br>
<br>
We need to find a way to have opam become a package like the others<br>
(with the exception of the embarked code for bootstrapping reasons),<br>
and have it become part of opam-repository... the main difficulty<br>
lies in the fact that its binaries need to go in special places,<br>
and not in the 4.00/3.12 etc. dirs (correct if I'm wrong)<br>
<br>
Once this is done, a sensible upgrade path would be:<br>
<br>
Time T : I have opam version n installed, accessing repo version n<br>
<br>
Time T+delta: some major changes make the old opam unable to use the new<br>
repository format, and the repository migrates to a new place;<br>
a new version n+1 of opam is released, embedding logic to access<br>
the new repository;<br>
opam version n+1 is added also to repo version n<br>
<br>
Sometimes later: the user of opam n runs an update, sees that a new<br>
version of opam is available, and upgrades it...<br>
he now has the new opam, that updates the references<br>
to the new repository, and keeps following the evolution<br>
of the repository, with no pain<br>
<br>
I know that maybe at some point the repo format will stabilise, but this<br>
simple process will make sure that the lambda-users (private joke: that's<br>
equivalent to "jow of the street" in french, but also hints at functional<br>
programmers :-)) will not get lost, no matter the changes.<br>
<br>
Any chances to see this happen soon? A starting point would be to summarize<br>
on this list the difficulties that prevent opam from being a "normal"<br>
package<br>
<br>
Cheers<br>
<br>
--<br>
Roberto<br>
_______________________________________________<br>
opam-devel mailing list<br>
<a href="mailto:opam-devel@lists.ocaml.org">opam-devel@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/listinfo/opam-devel</a><br>
</blockquote></div><br></div>