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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 6 Jan 2015, at 16:06, Roberto Di Cosmo <roberto@xxxxxxxxxxx> wrote:
> 
> 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

Thanks -- any guidance on not abusing this feature is most welcome or it
will inevitably happen ;-)

In general, we have a growing number of virtual packages in Mirage that
make depopts concrete dependencies.  For example, 'mirage-types-lwt', and
I'm considering adding a 'cohttp-lwt' and 'cohttp-async' package to make
those easier to depend on as well.

Provides would potentially invert a lot of this logic, since we could have
some virtual packages instead of lots of depopts.  Still not really sure if
this would work without more thought/experiments though...

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