[Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

[Angus Lees]

On Mon, 31 Aug 2015 at 19:26 Ximin Luo <infinity0 at debian.org> wrote:

> On 31/08/15 10:58, Sylvestre Ledru wrote:
> > Le 31/08/2015 10:37, Ximin Luo a écrit :
> >> On 31/08/15 08:59, Sylvestre Ledru wrote:
> >>> We are aware of this and we decided to take this approach on purpose
> for
> >>> now. This is not perfect but as rust is a moving target,
> >>> we took this shortcut. We hope they will be able to improve/fix that
> >>> upstream in the near future.
> >>>
> >> How is the hash generated and how do we guarantee that our hash matches
> with upstream's hash? Is there a way to calculate the hash *before* doing
> the build?
> > We are using upstream hash.
> >
>
> You could have been a bit more helpful. In fact the hash is generated only
> from the upstream version string, and *not* in the contents of the files
> (which is the first reasonable thought for things that are hashes).
>
> debian/rules:RUST_HASH := $(shell printf '%s' $(DEB_VERSION_UPSTREAM) |
> sed -e 's/\+dfsg[0-9]*$$//' | md5sum | head -c 8)
> configure:    CFG_HASH_COMMAND="$CFG_MD5 -q | cut -c 1-8"
> configure:    CFG_HASH_COMMAND="$CFG_MD5SUM | cut -c 1-8"
> mk/main.mk:CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) |
> $(CFG_HASH_COMMAND))
>
> So this actually contains no extra information than the strings (e.g.)
> "1.3.0" or "1.3.0-beta.3" or "1.3.0-nightly" etc, but has the disadvantage
> of not being comparable.
>

This is the case for libstd, but not for other dylibs.  The idea is that
it's a hash of the ABI - that is, the compiler version and the version of
every dependent library. For rustc/std itself, there are no dependent
libraries, hence this is just a hash of the compiler version.  I think it
would be wrong in the general case to make this just the source version
string.  In addition, ordering makes no sense on the library files -
"1.3.0" is potentially totally different symbol mangling and embedded LLVM
bitcode to "1.3.1", and there is no meaning to sorting the two, except that
it probably corresponds to the file mtime order.

I actually think the hash thing is a pretty neat take on symbol
versioning.  I'm not sure how much of the original vision is going to
survive whatever is required to declare ABI stability, however.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150831/528b658d/attachment.html>