(I'll answer the other things later) 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. I am wondering if we should just (a) patch this to use $(CFG_RELEASE) instead, and maybe (b) call the package libstd-rust-1, since semantic versioning is supposed to mean backwards compatibility between 1.3.0 and 1.2.0. That would be more sane, and I've asked in #rust about it. At the very least, debian/rules should refuse to build if libstd-rust-xxxx in the control file doesn't match RUST_HASH. I'll fix that up. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git