Apologies, I thought I did. Package versions consist of a version number and an optional slot. Constraints are a combination of disjunctive and conjunctive clauses in boolean logic. From http://dev.gentoo.org/~zmedico/portage/doc/pt02.html(which explains what portage does): "Each conjunctive clause represents one possible alternative combination of dependency atoms capable of satisfying the dependency expression." You also use lazy evaluation to defer the computation of concrete dependencies (i.e. a specific version) until as late as possible. (The docs are quite spartan in both words and layout).
So for slots distinguish the versions that you are trying to pick between - if you package only depends on slot 1, then you pick the highest version available in slot 1. If your package libraries have dependencies on a package with 2 different slots, both get installed. If you have a package whose libraries depend on incompatible versions of the same library (the definition of incompatible being what was specified in the packages that declare their dependencies) - then you get a resolution error. So your algorithm is a constraint solver essentially. libzypp took a similar approach (but more formal) - http://en.opensuse.org/openSUSE:Libzypp_satsolver. They also don't have multiple 'slots' (in RPMs the slot versions just become part of the package name). I think explicit slotting is cleaner though. I realise the above is still a bit hand-wavy still but it already works for portage ==> it should be implementable for rust. On Fri, Jan 31, 2014 at 8:37 PM, Tony Arcieri <[email protected]> wrote: > On Friday, January 31, 2014, Vladimir Lushnikov < > [email protected]> wrote: > >> There are some very interesting questions being raised here. >> > > You quoted my question (perhaps unintentionally) but didn't answer it... > > What algorithm do you use to resolve dependencies in a multi-versioned > world? For a world where you're searching (a DAG) for a set of mutually > compatible versions, toposort is an answer. But what about in a situation > where, based on a given set of constraints, you may or may not want to use > multiple versions of the same dependency? > > Unless there's an answer to this question, I think the rustpkg versioning > model is a total nonstarter. I will also note that all major dependency > resolvers (e.g. maven, bundler, apt-get, yum) calculate solutions which > consist of one particular version for each package. > > The "version compatibility is hard, let's go shopping!" school of thought > sounds nice in theory, but with nearly a decade of battle scars from > working with a system like that (RubyGems), my experience tells me it's a > terrible, terrible idea in practice... > > > -- > Tony Arcieri > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
