Problem with *.zip archives

[Andreas Tille]

Hi Joachim,

On Thu, Mar 20, 2014 at 12:14:37AM +0100, Joachim Breitner wrote:
> Am Mittwoch, den 19.03.2014, 23:04 +0100 schrieb Andreas Tille:
> > I'm testing the current status of uscan in devtools Git and noticed the
> > following when trying to update cimg-dev and mothur ... both coming as
> > zip archives:
> 
> thanks. Added as a test case and fixed.

Did you also pushed this change?

> Reading the log I get the
> impression that this was broken since January (9a6ba47); maybe the
> File-Excluded feature file somehow unbroke it.

I can confirm that I had some trouble with another zip archive in the
beginning of February but did not minded much ...

> I noticed that with my changes, it did not remove the Excluded-File
> file, because html/img/project-support.jpg does not match the full file
> name. Is there a precise specification about how entries should match?
> Anywhere in the file; the end of the file, the full file or the full
> file excluding the first directory?

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

In any case if this change was intentionally we should probably fix the
specification at

   https://wiki.debian.org/UscanEnhancements

as well.

> 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 stuff doesn’t quite work
> yet, but it would be nice to have a specification before I fix that.

May be it makes sense to work on the specification on the Wiki page
above.

Kind regards

      Andreas.

-- 
http://fam-tille.de