Problem with *.zip archives

[Andreas Tille]

Hi Joachim,

On Fri, Mar 21, 2014 at 12:34:07PM +0100, Joachim Breitner wrote:
> > 
> > In this case I personally would prefer fixing the test cases.  When I
> > stumbled upon the change I was thinking why somebody has drawn this
> > "decision" and cam e up with the idea that it might be that your
> > implementation is more safe in the case of "dirty" tar achives coming
> > with more than one unpackaging directory.  So if you consider this a
> > fair reason we should perhaps fix the specification to allow this (since
> > currently not so many use cases of Files-Excluded are out there).
> 
> Personally I’d find 
>         File-Excluded: foo/bar.js
> to exclude
>  * foo/bar.js (in case of a dirty tarball)
>  * pkg-1.0/foo/bar.js (as in your implementation) as well as
>  * pkg-1.0/docs/foo/bar.js (this would be new
> the easiest, as it will conceivably stand less in the way of the
> developers, i.e. he would _not_ have to first look up the precise
> semantics.

+1 (or rather +10 since it is really flexible ;-))

BTW, we should create a mothur-Package like test-case.  I just tested
your last commit and I can not get the __MACOSX go away. :-(

> Also, the implementation is easier: Just match $excluded as well as
> "*/$excluded" against the filename, with Text::Glob configured so that *
> also matches /.

+1
 
> Just found https://bugs.debian.org/685506 which contains an attempt to
> give a more formal specification. Good.
> 
> I suggest we replace
> 
>         
>         Patterns match pathnames that start at the root of the source
>         tree.
>         Thus, "Makefile.in" matches only the file at the root of the
>         tree, but "*/Makefile.in" matches at any depth.
>         
> with 
> 
>         Patterns match pathnames relative to any of their parent
>         directories. So "icons/company.png" matches such a file in the
>         root of the tree, in "pkg-1.0/icons/company.png" as well as in
>         "pkg-1.0/docs/icons/company.png".
>         
> This avoids the not well defined “root of the source tree”.

+1
 
> If that is not desired, I suggest we add
> 
>         The root of the source tree is the content of the single
>         top-level directory of the archive, if there is one; otherwise
>         it is the top level of the archive.
> 
> but I don’t really like this; Files-Excluded should not suddenly stop
> working because upstream accidentally included a ".mytags" file next to
> pkg-1.0 in the tarball.

I also prefer your first suggestion.
 
> > > > I guess there is no point in keeping zip files at all and changing them
> > > > to tar ... and by default to tar.xz if you ask me.
> > > 
> > > So do we need to support zip-to-zip File-Exclusion?
> > 
> > If you ask me - no.
> 
> James, what do you say? You once said
> 
> > Also, zip appears to support the same type of functionality required
> > to do the file exclusion on the archive directly.  Given that
> > Files-Excluded implies a repack, bailing out when the source archive
> > is a zip isn't desired.
> 
> Does that still hold, or is bailing out when the source archive is a zip
> *and the user did not specify --repack* desired?



I'd like to also say something for clarification:  I'd fully trust you
devscripts guys with way better Perl knowledge to do a way better job in
enhancing uscan than I could do.  I simply started with coding and
writing a specification since nobody else seemed to do this in the first
place.  I'd happily adopt to everything you invent as long as I can
easily cleanup my tarballs from unwanted stuff.


Remark:  My original patch also added an option to use

     --exclude-vcs

in the final tarball to cleanup VCS stuff generally.  This feature was
separated by Raphael since he considered it a different feature than
Files-Excluded (which is correct).  I just want to mention that I'd
regard this also as quite cool and would come up with a bug report once
the Files-Excluded + repack-compression features are fully implemented
and settled (and you are not faster with implementing this ;-)).

Kind regards

       Andreas.


-- 
http://fam-tille.de