[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] [opam-devel] 'provides' field design proposal
> * 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |