Hi Joachim, On Thu, Mar 13, 2014 at 02:49:00PM +0100, Joachim Breitner wrote: > > > > I hope you are aware that taring up two byte identical trees usually > > does not lead to a byte identical tarball. > > Well, I was hoping that uscan would not simply create new tarballs, but > rather removing it from the tarfile, which seems to be deterministic: > > $ zcat haskell-mtl_2.1.2.orig.tar.gz | md5sum - > bac0c479109021b9d2b3696a0b001f5a - > $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | > md5sum - > 0ef3b46f5e345521fd40bc634e0fc1d1 - > $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | > md5sum - > 0ef3b46f5e345521fd40bc634e0fc1d1 - > $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | > gzip -n | md5sum - > 909d962dacabbf1c5430df2ac1c20ef3 - > $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | > gzip -n | md5sum - > 909d962dacabbf1c5430df2ac1c20ef3 - > > (This is probably equivalent to what Mike does in python.)
I admit that I simply failed to consider this option when implementing Files-Excluded and when thinking about it I'm not sure how this should elegantly work together with `find` to exclude groups of files reasonably. My original patch to implement Files-Excluded contained another feature described in #730768 (and fixed in Git as I just realised) to enable better compression once we are loosing the "same MD5sum feature" anyway. >From my perspective this definitely would outweight the fact that two different persons would get a byte identical result. For historical reasons and to simplify the acceptance of the whole patch Rafael Laboissiere has split those two functions into two separate patches (and according bug reports) and these made their way into different releases of devscripts. In short: I consider the repackaging as a solution that works in the same way as before when there were reasons to repack something (*.zip) which if you want to use extra features like better compression does not have any visible drawbacks. I agree that your "--delete" solution looks more clean but would need somebody who might implement this. > Of course I could change my workflow to cope with a non-deterministic > "uscan --download", so this is not very important. But then, this thread > is all about what level of convenience we allow ourselves, and what we > spend our time on. Exactly. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313141403.gh7...@an3as.eu