[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