[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jquery debate with upstrea



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


Reply to: