[opam-devel] 'provides' field design proposal
Roberto Di Cosmo
roberto at dicosmo.org
Tue Jan 6 16:06:44 GMT 2015
Dear Louis,
best whishes for a happy new 2015!
Thanks for sharing this proposal: it's quite well argumented,
and allows to discuss the new issues nicely.
Here is some info that will be useful in evolving the proposal:
- CUDF already supports provides, so the mechanics inside Dose to
handle them are all in place already.
- Notice that Debian did not have versioned provides, so when
a versioned dependency was present, only real packages needed
to be considered https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
Encoding this policy in CUDF required some nonobvious gymnastics
that is implemented in the Dose code for handling Debian packages.
Implementing directly versioned provides as you suggest will make
the encoding in CUDF straightforward, even if we might stumble upon some
little tested code here, but well, we'll be quick at fixing
any issues that may emerge
- I do not see a real semantic confusion between "provides" and "features", but
I am not against using "traits" (or "variants") if it seems clearer
- To address Anil's concerns: provides are just a very convenient way for
expressing disjunctions in a modular way, and they are actually expanded
as disjunctions for the solvers, so I do not foresee any performance issue,
unless we heavily abuse this features
--
Roberto
On Tue, Jan 06, 2015 at 03:39:18PM +0000, Anil Madhavapeddy wrote:
> Looks great, Louis! My immediate thoughts:
>
> - This does have the potential to complicating pinning quite a lot, which
> needs to be balanced against the better upgrade messages. Do you think
> this will need a package selection priority the way that apt-pinning in
> Debian works (e.g. so that ocaml-tls can be selected ahead of openssl-tls
> for the TLS package).
>
> - The forking and providing replacements would be really useful for Mirage,
> where we're having an active discussion about how to provide Xen-specific
> versions of certain packages such as Zarith. Thomas (with any surname),
> opinions on this?
>
> - How much damage will this do to the internal solver heuristics?
>
> -anil
>
> > On 5 Jan 2015, at 08:36, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
> >
> > Hi all, and happy new year !
> >
> > I just added to opam a design proposal to open discussion on the implementation of the 'provides' field and its use-cases.
> >
> > It's at https://github.com/ocaml/opam/blob/master/doc/design/provides.md
> >
> > Cheers,
> > Louis
> > _______________________________________________
> > opam-devel mailing list
> > opam-devel at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/opam-devel
> >
>
> _______________________________________________
> 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