[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...
Anil
More information about the opam-devel
mailing list