Ryan Lortie wrote:
> + * Add 'tarignore' and 'diffignore' functionality
> + - list files (eg: '.git' or '.bzr') one per line to debian/tarignore
> + for dpkg-source -b to exclude them from the tarball
> + - list regexps one per line to debian/diffignore for dpkg-source -b
> + to exclude them from the diff
> + - lines starting with '#' are comments
> + - blank lines ignored
> + - empty file means to use the default (same as '-i' on command line)
dpkg-source options -I and -i already solve the problem of excluding
files from a tarball and diff. That works well for excluding revision
control system files. Why would you want to put this information about
the revision control system you're using into the source package?
I suppose that diffignore could be used as an alternative to a proper
debian/rules clean target, if the build modifies some files and it's
too much bother to undo the modifications in clean. But is there really
a benefit from making it easier to write clean rules that don't fully
clean the build tree? What if the someone later needs to modify the
diffignored files to fix an issue in the package? They then build a
source package, and it silently fails to include their modifications!
Also, as implemented, dpkg-source -i overules the diffignore file. So if
you put a file in diffignore, everyone who builds the package has to be
very careful not to use dpkg-source -i. Inconsistently, dpkg-source -I
doesn't override the tarignore file. (Nor does an empty tarignore file
lead to the default -I behavior, like an empty diffignore does.)
Finally, the regexps in debian/diffignore can be used to cause
dpkg-source to run arbitrary code (embedded in the regexp via (?{ code })
when building a source package. This is not as dire as if it ran arbitrary
code when unpacking a source package, but it is still a new security issue,
and I think dpkg-source should be safe to use to build source packages
without worrying about code injection.
(BTW, your YY_TEXTPOINTER change seems to have nothing to do with
rest of the patch.)
> Pending further review this will be in Ubuntu's dpkg soon.
I have the same opinion of unnecessarily diverging ubuntu and debian's
dpkg as I have of diverging debhelper. It will come back to haunt all of
us. If you think it won't, just look at the gawdawful mess rpm has been
in over the past few years, with each vendor maintaining slightly
incompatible versions.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature