[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))
Roberto Di Cosmo
roberto at dicosmo.org
Sat Feb 1 10:50:07 GMT 2014
Hi Ashish, sure, having the repo format information clearly available will
surely help, that's a good idea.
But the real good solution is to make sure the proper upgrade trail can be
automatically followed from whatever original state you are in, and that
is not difficult to do :-)
On Fri, Jan 31, 2014 at 01:14:45PM -0500, Ashish Agarwal wrote:
> 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 opam.ocaml.org (or whichever repo it is),
> then you have to upgrade opam".
>
> 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.
>
> In all cases, it should be considered that https://opam.ocaml.org must remain
> the main repo URL. It is the nice URL and we don't want to have the next repo
> be at https://opam2.ocaml.org.
>
>
>
>
> On Fri, Jan 31, 2014 at 12:28 PM, Roberto Di Cosmo <roberto at dicosmo.org> wrote:
>
> [I am moving this discussion away from the BTS and into
> the mailing list, as the issues raised here are of
> general relevance for the future of Opam, and must
> not be lost in the middle of other comments; see
> https://github.com/ocaml/opam/pull/1149 for the original
> discussion
> --
> Roberto
> ]
>
> The original issue: what build system should we use to build opam?
> Should we cook up an ad-hoc Makefile, use a patched ocamlbuild,
> or use OCamlMakefile, or use ocp-build? Is it evil to embark
> a build system in the package manager source code?
>
> My quick view of these issues:
>
> 1) choice of the build system
>
> we are already plagued with multiple build systems, and one of the
> reason
> of opam's success is that it allows every package author the freedom
> to use
> the one he/she prefers/ is more comfortable with.
> Opam is no exception, and opam developers must be able to pick the
> build system
> they prefer, so I would say, it's their decision to make
>
> 2) embarking a full build system into the source tree of a package
>
> in general I would find this a very bad idea: one should have a
> separate
> package for the build system, and have it installed before building
> anything else.
>
> Now, what sets opam apart from other OCaml components is the fact that
> it is
> the *basic* building block for all the other packages in the
> repository, and
> without a running opam, there is no way to install any other package;
> this
> is a bootstrap issue, and that's why, for example, opam embarks in
> src_ext
> the full source of the dose and libcudf libraries, instead of linking
> to
> the packages for dose and libcudf (that do exist in the repository);
> so
> in this particular case *only* I personally would not be shocked to
> see
> some extra stuff in the src_ext directory (especially considering that
> all this will need to work on multiple platforms)
>
> 3) how do we update opam?
>
> Now, for another important issue, related to the special status of
> opam
> as *the* package manager, and how we should manage it (hence the title
> of this message).
>
> I am a bit unhappy with the current state of affairs, where new
> versions of opam appear with incompatible changes in the repository
> format,
> hence different versions of the repositories: people using old
> versions
> of opam get lost in a limbo-like repository with non updated packages
> until they realise they need to recompile a new version of opam
> to see the light again.
>
> We need to find a way to have opam become a package like the others
> (with the exception of the embarked code for bootstrapping reasons),
> and have it become part of opam-repository... the main difficulty
> lies in the fact that its binaries need to go in special places,
> and not in the 4.00/3.12 etc. dirs (correct if I'm wrong)
>
> Once this is done, a sensible upgrade path would be:
>
> Time T : I have opam version n installed, accessing repo version n
>
> Time T+delta: some major changes make the old opam unable to use the
> new
> repository format, and the repository migrates to a new
> place;
> a new version n+1 of opam is released, embedding logic to
> access
> the new repository;
> opam version n+1 is added also to repo version n
>
> Sometimes later: the user of opam n runs an update, sees that a new
> version of opam is available, and upgrades it...
> he now has the new opam, that updates the references
> to the new repository, and keeps following the
> evolution
> of the repository, with no pain
>
> I know that maybe at some point the repo format will stabilise, but
> this
> simple process will make sure that the lambda-users (private joke:
> that's
> equivalent to "jow of the street" in french, but also hints at
> functional
> programmers :-)) will not get lost, no matter the changes.
>
> Any chances to see this happen soon? A starting point would be to
> summarize
> on this list the difficulties that prevent opam from being a "normal"
> package
>
> Cheers
>
> --
> Roberto
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>
>
--
Roberto Di Cosmo
------------------------------------------------------------------
Professeur En delegation a l'INRIA
PPS E-mail: roberto at dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
FRANCE. Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
Bureau 3020 (3rd floor)
Batiment Sophie Germain
Avenue de France
Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
More information about the opam-devel
mailing list