Problem with *.zip archives
Andreas Tille
tille at debian.org
Fri Mar 21 12:43:03 UTC 2014
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
More information about the devscripts-devel
mailing list