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

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> * 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.

Not sure I understand that part. Would it be simpler to always require that 
"provides" contains the name(s) of concrete package(s)? Supporting "virtual 
packages" means that we have 2 ways to do the same things: depots and provides. 
Which means it is harder to explain to the user what to use when.

I think the goal of "provides" should be "just" a simple way to provide 
slightly patched opam packages without requiring hackish pining, not a way to 
expose in the "provides" all the modules/implementations provided by an opam 
package (although it could be a good idea too, but I think should be kept out 
of the scope of that proposal).

Thomas

> 
> * 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
>>> 
> _______________________________________________
> 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