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

Johannes Schauer josch at debian.org
Mon Jul 17 10:47:42 UTC 2017


Quoting Ian Jackson (2017-07-17 11:31:07)
> That would be a perfectly fine answer from my point of view.  However,
> it has a few different behaviours.  I'm not sure what is best.
> 
> Things I thought of:
> 
> 1. If there are files which are ignored, or uncommitted, this would
>    use the committed files.  I think this is a benefit.
> 
> 2. Using git this way means git is definitely in the chroot.
>    But a package might build differently.  For example, it might
>    have a stealth b-dep on git, which this approach wouldn't detect.
>    I think this is a downside of using git.

The only assumption sbuild should make about the chroot is, that all
Essential:yes packages are installed and that apt is installed and able to
install more packages. Starting from this situation sbuild should be able to
install anything that's needed to carry out the build like build-essential. It
is not impossible to only temporarily install git for unpacking the bundle and
to then remove and autoremove it before dpkg-buildpackage is run.

> 3. The git approach cannot be easily used with a different VCS.

The switch could be git-specific in which case it's up to the user to make sure
that the underlying VCS is really git.

If the new switch is not git-specific then sbuild could auto-detect whether
it's git (and then do git-ish stuff) or not (and then just make a tarball).

> 4. Building and unpacking a git bundle is pointless work when we know that
>    the destination completely trusts the source, and does not have any
>    objects already.  A tarball would do.

Indeed a git bundle is overkill because dpkg-buildpackage inside the chroot is
not interested in the history stored in the bundle. But just using "tar" would
not have the advantages of item 1. So "git archive" should be used together
with its disadvantages (and workaround) from item 3.

> From the point of view of a dgit user, item 1 is quite important and IMO
> outweighs the other considerations.

Agreed.

I wonder what the best interface for this feature would be. Even more if we
consider this a long term feature, existing git workflows as well as dgit...

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170717/00dbe953/attachment-0001.sig>


More information about the Buildd-tools-devel mailing list