[opam-devel] 'provides' field design proposal

[Thomas Gazagnaire]

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

repo + up-to-date headers is fine (and adding the right headers to other design spec as well)

Thomas


>> - 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 at ocamlpro.com> 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 at lists.ocaml.org
>>> http://lists.ocaml.org/listinfo/opam-devel
>>> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel