[Pkg-rust-maintainers] Rust dylib hash versions

[Ximin Luo]

(moving off the bug report)

On 31/08/15 15:22, Angus Lees wrote:
> On Mon, 31 Aug 2015 at 19:26 Ximin Luo <infinity0 at debian.org <mailto: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.
> 

It's helpful for the human looking at it to know if it's a newer or older version of the library. I like hashes too, but not at the expense of knowing what's going on...

In general, for other dylibs, I'd argue that filenames are expected, primarily, to describe the content itself and not its dependencies, which is secondary metadata. A name like

lib$name-$version-$hash_of_dependencies_and_compiler

would bring in the best of both worlds. In the case of rust's standard library, this reduces down to:

libstd-$version-$hash_of_compiler which reduces down to:

libstd-$version

since there is actually no extra information in the hash. If we want to bundle extra information in there (such as the compiler used to compile the compiler) this would become

libstd-$version-$hash_of_compiler_deps

All of these given a better idea to the human *what is in there*, but a hash by itself doesn't.

(wondering if we should continue this discussion at https://github.com/rust-lang/rust/issues/28120)

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git