[rust-dev] Deprecating rustpkg

Vladimir Lushnikov vladimir at slate-project.org
Fri Jan 31 12:51:57 PST 2014

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 <bascule at gmail.com> wrote:

> On Friday, January 31, 2014, Vladimir Lushnikov <
> vladimir at slate-project.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/c2b02af8/attachment.html>

More information about the Rust-dev mailing list