[buildd-tools-devel] Bug#868527: want sbuild --no-source or something

Ian Jackson ijackson at chiark.greenend.org.uk
Sun Jul 16 12:32:17 UTC 2017


Package: sbuild
Version: 0.73.0-4
Severity: wishlist

It would be nice if it were easier to use sbuild with a gitish
downstream workflow which does not produce "3.0 (quilt)" source
packages.

For example, consider this scenario:

   dgit clone foo stretch
   cd foo
   hack hack hack
   git commit
   git merge upstream/stable
   hack hack hack
   git commit
   gbp dch
   sbuild -A
   dpkg -iGOEB ../*.deb

This is similar to the recommendatioms in dgit-user(7), except that we
are trying to use sbuild.

The above attempt will probably fail.

This is because the package "foo" is probably "3.0 (quilt)", according
to debian/source/format.  sbuild will try to build a source package,
and dpkg-source will want the user's changes to be "committed" as
patches in debian/patches.  The user won't have done that and probably
doesn't want to.  Worse, in the general case, changes might be made to
the git tree which dpkg-source cannot represent.

The solution is to not build a source package.  The user who adopts a
gitish workflow probably doesn't want one.  However, sbuild needs a
source package because that's how it transfers the package into the
chroot.

I suggest that sbuild grow an option which generates a dummy source
package in some hidden or temporary place.  I think the actual source
package generation can be done with something like this rune (and that
this will always succeed):
  dpkg-source -Zgzip -z0 --format=1.0 -sn
(but I have not yet tested this myself).

I don't have much of an opinion what the sbuild option should be
called.  --no-source is a possibility.  Or maybe it should be inferred
from the other options and the fact that sbuild is working from a
directory tree - although that would be an incompatible change.

In the meantime, I think users can use
  sbuild -A --dpkg-source-opts='-Zgzip -z0 --format=1.0 -sn'
However, that sets up a hazard: it produces a dummy 1.0 native tarball
package as if it were a build product.  But that native tarball
package is broken: it can be extracted and built, but it cannot be
re-packed, without again providing special optionsn to dpkg-source.

Thanks,
Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



More information about the Buildd-tools-devel mailing list