[rust-dev] Deprecating rustpkg

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

There are some very interesting questions being raised here. I think I can
add to the discussion:

[A] The problem of each version being in its own namespace can be solved by
"slots" (at least that's what portage calls them). See

Basically you allow package authors to specify versions where there the ABI
doesn't change (I think this is completely orthogonal to the hashing of
library symbols etc) and versions where the ABI does change. So if you care
about a particular version in your rust lib, you can specify either a
version (1.0 > version and version < 2.0 if you want something more than
1.0 but less than 2.0) or a slot or both.

So the algorithm can still be a variant of top sort, just taking the
additional constraint of (optional) slots into account.

[B] Java's mistake with namespaces is made clear by the need for OSGI
containers in the first place.

I don't think there is anything stopping the rust linker for when it
encounters a program that depends on the two libraries (let's call them A
and B) that pull in library C (but A pulls in C version 1.0, slot 1 and B
pulls in C version 2.0, slot 2) to just link the two different versions of
the library in:

                 A  --> C (version 1.0 slot 1)
program /
                 B --> C (version 2.0 slot 2)

Of course, say that this wasn't the case, and both A and B pulled in
different versions of C with slot 1, then you'd potentially have a link
conflict if public symbols were removed during that time and you simply
pick the highest version.

This isn't possible in Java or C++ because the language doesn't allow for
such fine distinctions (and so you see projects like xerces and others try
putting new versions in the namespace itself which is yuk).

[C] (other thoughts)

I think the idea of rustpkg should definitely not be abandoned. There is a
need for a tool to address concerns such as:

* Package identity (this is package A, signed by developer A etc.)
* Package versioning (this is package version 1.0 with slot 1 - see comment
* Package versioning for -SNAPSHOT (-style) versions taken from VCS
* Build-time dependency resolution
* Reliably building packages from source
* Location-agnostic package finding (something like pypi would be a good
start, but obviously decentralized architectures can be more resilient)
* Deterministic builds (yes, the package manager should try to have a
stable dependency resolution algorithm etc)
* Provide the idea of **contained** packages (see virtualenv for python or
GEM_HOME & others)

(Some of these ideas were inspired by http://nixos.org/nixos/ and
http://wiki.gentoo.org/wiki/Project:Portage , both of which are well worth
having a look at if you haven't come across them before)


On Fri, Jan 31, 2014 at 6:14 PM, Tony Arcieri <bascule at gmail.com> wrote:

> On Fri, Jan 31, 2014 at 10:12 AM, Strahinja Markovic <val at markovic.io>wrote:
>> You depend on the latest version of a lib or on a specific, explicit
>> version. People who don't care about the old version use the latest, and
>> people who need the old lib version because they haven't updated use that.
> What algorithm do you use to resolve dependencies in a multi-versioned
> world?

> --
> Tony Arcieri
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/a398152e/attachment.html>

More information about the Rust-dev mailing list