[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