Problem with *.zip archives

[Joachim Breitner]

Hi,

Am Freitag, den 21.03.2014, 11:53 +0100 schrieb Andreas Tille:
> > > When I proposed my first implementation the Files-Excluded was relative
> > > to the unpackaging dir and html/img/project-support.jpg.  Yesterday I
> > > learned (with some non-zip archive) that the implementation has changed
> > > to the root of the tar archive and thus now the correct way to specify
> > > the exclusion would be:
> > > 
> > >    Files-Excluded: */html/img/project-support.jpg
> > > 
> > > I simply assumed that the devscripts developers have good reasons for
> > > this change and I do not mind much (except that I need to remember to
> > > change some d/copyright files accordingly).
> > 
> > No, that was just me, based on what the testcases did (I like
> > implementing along testcases) and later realized that it is not what
> > others do. 
> 
> 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.

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

> > > In any case if this change was intentionally we should probably fix the
> > > specification at
> > > 
> > >    https://wiki.debian.org/UscanEnhancements
> > > 
> > > as well.
> > 
> > Ok, if that is the specification, I can adjust the implementation to
> > match the specification, which also dictates that * should match / and .
> > as well.

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”.


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’m having some trouble getting the Text::Glob to do what I want,
> > > > especially with the Excluding-file-from-zip-without---repack that I was
> > > > asked to put back in (do we really need that? Who uses uscan to download
> > > > zip files without repacking them to tar),
> > > 
> > > 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?

Greetings,
Joachim



-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20140321/397c0182/attachment-0001.sig>