Re: [MirageOS-devel] [opam-devel] 'provides' field design proposal

[Louis Gesbert <louis.gesbert@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > http://lists.ocaml.org/listinfo/opam-devel
> > 

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel