Federico Beffa <be...@ieee.org> skribis: > On Wed, Jul 22, 2015 at 11:10 PM, Ludovic Courtès <l...@gnu.org> wrote: >> Federico Beffa <be...@ieee.org> skribis: >> >>> (sha256 >>> (base32 >>> "06mc7kh3fzdh2mqkyynjnp0xpv30yfaiik8bqv8z5b6hldji3cky")))) >> >> [...] >> >>> (sha256 >>> (base32 >>> "06mc7kh3fzdh2mqkyynjnp0xpv30yfaiik8bqv8z5b6hldji3cky")))) >> >> Both recipes are telling that they use the same source. So the daemon >> cleverly saves one download since it already has the thing with that >> hash on disk. See? :-) > > Thanks for the reply! > > I thought about this and, before posting, I also tried with an hash > where the first character was changed from '0' to '6'. It gave the > same result, even after deleting any existing 'emacs-dash' and > 'emacs-s' derivation in the store. In my understanding that shouldn't > happen. Is that correct?
Right, but we’d have to check the exact sequence of actions that you took. > By changing the hash to a totally different one (a string of '6's) it > downloads the right repo. As expected, it complains about the hash and > gives me the right one which I can copy into the package recipe. > (That's The Lazy work-flow :-).) Heh. :-) It’s a good idea to clone by hand though and check the signatures if there are signed tags or commits (“trust on first clone”), but I’m afraid this is not commonplace. Ludo’.
