Steven Chamberlain <> (2016-10-12):
> Suppose a debian-installer source package is produced this way:
> $ debcheckout debian-installer
> $ cd debian-installer
> $ debuild -S
> [...]
> dpkg-source: warning: no source format specified in debian/source/format, see 
> dpkg-source(1)
> dpkg-source: warning: source directory 'debian-installer' is not 
> <sourcepackage>-<upstreamversion> 'debian-installer-20160704'
> dpkg-source: info: using source format '1.0'
> dpkg-source: info: building debian-installer in 
> debian-installer_20160704.tar.gz
> dpkg-source: info: building debian-installer in debian-installer_20160704.dsc
> In source format 1.0, dpkg-source does *not* exclude the .git/ directory
> from the generated tarball!  So if you built the source package that way,
> your Git working tree's refs and config are all included in the upload,
> which happened with my uploads here:

debcheckout's output lets you know you're getting a git repository. I'm
not sure running debuild -S without -i/-I makes this an important bug in

> Note that source format 1.0 is only used because one is not specified in
> debian/source/format.  dpkg-source(1) recommends to specify a version and
> the lack of a debian/source/format file may be considered an error in
> future.

I don't like the idea of unneeded boilerplate in source packages just
because dpkg developers want to force v3 onto people so badly.

> dpkg-source(1) also recommends choosing a newer format.  3.0 (native)
> by default already excludes VCS directories such as .git/ from the
> generated tarball, already fixing the issue above.
> 3.0 (native) does however default to .tar.xz compression, rather than
> .tar.gz as used at the moment.  I'm not sure if that may be an issue for
> other tools.  Maybe they should be fixed in that case.  Or _if_ it's
> preferred to still use .tar.gz, that could be specified in
> debian/source/options:
>     compression = "gzip"

scripts/debian/byhand-di doesn't seem to look at something which isn't
the images tarball; I'm not sure whether something else might needed
being looked at.

> Attached is my proposed patch, for consideration.

In case someone wants to merge this, I would like to see this very
carefully reviewed for possible side effects. Getting an error during
the next release, or worse a regression only seen afterwards, would
really be annoying.


Attachment: signature.asc
Description: Digital signature

Reply via email to