[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#685506: marked as done (copyright-format: new Files-Excluded field)

Your message dated Mon, 12 May 2014 16:33:35 +0200
with message-id <1399905215.19455.12.camel@kirk>
and subject line Re: mk-origtargz: Use the already parsed $data to check for Files-Excluded
has caused the Debian Bug report #685506,
regarding copyright-format: new Files-Excluded field
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
685506: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685506
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy
Severity: minor

Hello,

there was some discussion on debian-devel@l.d.o about enabling uscan to
remove files from an upstream tarball automatically.  In this discussion
(first mentioning was here:

  http://lists.debian.org/debian-devel/2012/08/msg00406.html

) the idea occured that it makes perfectly sense to mention files which
are excluded from the tarball inside the debian/copyright file.  From my
perspective this makes sense in any case (independently whether uscan
does any automatic job here or not.)  Please note that this problem is
somehow connected to bug #561494.

I would propose the following addition to 

  http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

----------------------- 8< ---------------------------------------------
Files-Excluded
--------------

Whitespace-separated list: list of patterns indicating files removed
from upstream source.

# begin copy of Files field description

Filename patterns in the Files field are specified using a simplified
shell glob syntax. Patterns are separated by whitespace.

Only the wildcards * and ? apply; the former matches any number of
characters (including none), the latter a single character. Both match
slashs (/) and leading dots, unlike shell globs. The pattern *.in
therefore matches any file whose name ends in .in anywhere in the source
tree, not just at the top level.

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.

The backslash (\) is used to remove the magic from the next character;
see table below.

Escape sequence	Matches
\*	star (asterisk)
\?	question mark
\\	backslashAny other character following a backslash is an error.

This is the same pattern syntax as fnmatch(3) without the FNM_PATHNAME
flag, or the argument to the -path test of the GNU find command, except
that [] wildcards are not recognized.

# end copy of Files field description

The field is optional and should be specified in connection with the
Source field.
----------------------- >8 ---------------------------------------------

Kind regards

        Andreas.

-- System Information:
Debian Release: 6.0.5
Architecture: i386 (i686)

Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message --- 
Version: 2.14.2

Hi,

Am Montag, den 12.05.2014, 09:59 +0200 schrieb Andreas Tille:
> I realised that the latest devscripts upload now also includes the
> --compression option.  Thanks for all your work on this.  While I think
> that even the previous version fixed #685506 I wonder whether you kept
> this bug open intentionally.  From my point of view it can be closed.

I agree, that makes two of us, closing.

> I have adapted the wiki page about uscan enhancements[1] since all major
> points seem to be solved now.  The only remaining item was to enable a
> trigger for "tar --exclude-vcs" which now should probably go to
> mk-origtargz.  I just think that it is sensible to have an option to
> drop all the VCS stuff inside upstream tarballs.

Again, I’m opposed to silently do stuff with user’s data that he did not
explicitly asked for. What if upstream decides that he wants the git
repo in the tarball (after all, it is a distributed VCS, so why not
distribute it) and the build process uses it to calculate, say, the
version number and a change log at built time.

I don’t mind an option "--exclude-vcs" to mk-origtargz (and uscan) that
works like "--exclude-file .git --exclude-file _darcs" ...

> I'm going to file a bug report about this if you will not beat me with
> implementing this in Git first.  I think the implementation is pretty
> easy and any patch of mine will just pester you with my naming choice
> which has not proven the best one in the past and thus I would hesitate
> to send a patch.

It’s not as trivial as you think it might be. Currently, mk-origtarz
uses "tar --delete" and never actually unpacks the tarfile. But
--exclude-vcs does not work with --delete:

$ tar tf foo.tar 
foo/
foo/.git/
foo/.git/a
foo/b
$ tar --delete --file foo.tar --exclude-vcs
$ tar tf foo.tar 
foo/
foo/.git/
foo/.git/a
foo/b

It would probably work easiest by simply listing the various glob
patterns in mk-origtargz directly, like in the "origtarz" script, or use
@Dpkg::Source::Package::tar_ignore_default_pattern (from libdpkg-perl).

Do you also want options --exclude-backups, --exclude-caches,
--exclude-caches-all, --exclude-caches-under, .... :-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: