Quoting Ian Jackson (2017-07-16 14:32:17) > 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. > > [snip] > > 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.
Indeed, the task to solve is how to transfer the source into the chroot. But is $(dpkg-source -Zgzip -z0 --format=1.0 -sn) really the right thing to do? Would it not be more fitting to use some git-based command to exchange the data? For example using a git bundle? This would then make sure that everything git knows about is transferred into the chroot. Sbuild can make sure that git gets installed together with build-essential and is thus able to git unbundle the file. What do you think? Thanks! cheers, josch
signature.asc
Description: signature
