On Jan 31, 2014, at 12:23 PM, Vladimir Lushnikov <[email protected]>
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.
-Kevin
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
