[rust-dev] Deprecating rustpkg

Kevin Ballard kevin at sb.org
Fri Jan 31 12:32:01 PST 2014

On Jan 31, 2014, at 12:23 PM, Vladimir Lushnikov <vladimir at slate-project.org> wrote:

> 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.

I don't know how much of an issue this is in practice, but such a system has two flaws that I can see:

1) It relies on the library author correctly identifying when they've made an API change. Any mistakes on their part will lead to problems down the line for customers.

2) Even non-API changes are sometimes important to customers. Notably, bug fixes, especially if they break previously-implemented workarounds.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/a7f34202/attachment.html>

More information about the Rust-dev mailing list