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 _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
