[opam-devel] 'provides' field design proposal

[Louis Gesbert]

Some follow-ups, before updating the design document:

* On pinning: pinning a source clearly implies this is a concrete package (or becomes one); on the other hand, pinning a version should only be allowed for concrete packages. With this limitations I think we can sort it out without too much trouble. Since any virtual package has to be provided by some concrete package, you can always pin those, or create your own package with the same "provides" and pin it.

* internal heuristics: as Roberto pointed out, this his handled by Dose, so shouldn't be too much trouble either (but given the nature of this code, it's impossible to be sure at the moment). A rewrite to ORed depends is possible in the worst case, but adding a layer at that stage would probably mess up user messages ; it should really not be needed.

* checking concrete dependencies: not sure how that would be covered by 'provides', as it is the conjunction of several packages that provides the new one (cohttp + lwt => cohttp-lwt). It seems closer to the 'features' stuff, but you can't _depend_ on a feature with the current design (restricting features definitions to package formulas may make it possible though; I'll think about it)...
  Another possibility, maybe (but interaction with cudf would need to be carefully studied, because we are getting out of what is supported), would be to have additional formulas on 'provides':
  cohttp/ provides: [ "cohttp-lwt" { lwt } ]
  In terms of rewriting it doesn't seem much more difficult, virtual package cohttp-lwt would include ("cohttp" & "lwt") in its depends disjunction instead of just "cohttp". Anyway, we can easily leave that part for later.

* new question: if I have several packages providing Foo, should I recompile a package depending on Foo whenever one of them changes ? I'd say yes...

* Location of design documents: not sure at all this is best, because versionning of the design document (at least during the design phase) doesn't need to be synchronized with the source, but it has its advantages, and I don't like github's wikis much. Seemed more practical for something in-depth than just an issue. Do you suggest another option ? Adding headers is a good idea.

Cheers!
Louis

> - Anil Madhavapeddy, 06/01/2015 15:39 -
> 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
> >