[opam-devel] 'provides' field design proposal

Anil Madhavapeddy anil at recoil.org
Tue Jan 6 16:21:00 GMT 2015

On 6 Jan 2015, at 16:06, Roberto Di Cosmo <roberto at dicosmo.org> 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...


More information about the opam-devel mailing list