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 http://devmanual.gentoo.org/general-concepts/slotting/ 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 above) * 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) Vlad On Fri, Jan 31, 2014 at 6:14 PM, Tony Arcieri <[email protected]> wrote: > On Fri, Jan 31, 2014 at 10:12 AM, Strahinja Markovic <[email protected]>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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
