Hi, Quoting Ian Jackson (2016-12-15 21:25:53) > dgit has wrappers for lots of build tools, including sbuild, > git-buildpackage, dpkg-buildpackage, and hopefully soon pbuilder > (#844125). > > This is because the default ignore rules (in dpkg-source) ignore > .gitignore, but dgit needs the source package to contain (any changes > to) .gitignore. So dgit arranges that (if you use dgit to do the > build-for-upload) dpkg-source gets passed -i\.git/ -I.git. > > Having dgit users have to use dgit as the way to invoke their builder > is undesirable. It means a bigger disruption to their workflow and > adds yet another layer to what is often quite a tall stack. > > What would you think (particularly, sbuild and pbuilder folks) about a > supporting a --dgit option ? The effect would be to pass -i\.git/ > -I.git to dpkg-source. (Possibly there might be other effects which > would be desirable, but this is the only essential one for those two > tools I think.) sbuild already has an option to do just that: $ sbuild --dpkg-source-opts="-i\.git/ -I.git" ... Or by putting the following in the config file: $dpkg_source_opts = ["-i\\.git/", "-I.git"]; (hope I got all the backslash escaping right there). Unfortunately, typing this is much more involved than just putting --dgit but maybe we can do even better. I wonder: - are there other git-based workflows than dgit which need these cleaning options? Then the option name could be picked to be more general and not dgit specific - is there a reliable and future-proof way for sbuild/pbuilder to auto-detect that they are working on a dgit package? Maybe by examining the Vcs-Git field? Then they could pick the right options for dpkg-source automatically. Otherwise (and also being a dgit user myself) I'm open to adding a --dgit option to sbuild. I'd just want to hear your ideas about the above first because I don't want to add an option just to deprecate it one release later. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature