[rust-dev] Deprecating rustpkg

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


I agree, the system is flawed as it relies upon the original developer. But
because IMHO we should be considering a build-from-source approach (like
python, unlike Java) it is also easy to fix - just create a fork with the
changes you want. Certainly that is what we do with quite a few libraries
that we use at work (minor changes but still crucial to work with our
software). Of course that doesn't work for binary software, but I don't
think any solution can really address that well.

I wonder if there is appetite for an API compatibility tool that scans your
upgraded library versions and warns you when the public api has changed?
Obviously in the Java world you just upgrade and run your test suite + the
compiler to do that. Also, isn't the rust crate metadata sufficiently rich
to encode at least a subset of the public api reliably? (I'm not sure)






On Fri, Jan 31, 2014 at 8:32 PM, Kevin Ballard <kevin at sb.org> wrote:

> 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.
>
> -Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/24ad8c95/attachment-0001.html>


More information about the Rust-dev mailing list