Hello, On Thu, Jun 21 2018, Ian Jackson wrote:
>> This might be a reason to not remove but instead firmly deprecate >> build-source, until one can dgit push to security-master. > > I don't really mind deprecating it. Dropping it entirely would be a > different matter. It might be embedded in people's workflows. FTR > I'm the kind of person who takes ages to remove old stuff. Fair enough. I'd like to both deprecate in the docs and add some output saying it's deprecated. >> The reason for limiting dgit subcommands in this way is to restrict >> dgit's role to being the bidirectional archive<>git gateway, not an >> all purpose Debian packaging wrapper script like git-buildpackage is. > > I keep saying this: I would love for dgit not to be a general purpose > wrapper but until the .gitignore bug is fixed in all other tools it > will have to continue to be so (and then for some time afterwards). > > (Also, -wgf.) > > I mind much less that dgit is a general purpose wrapper (even though I > have to maintain and test a stupid pile of wrapper and command line > parsing code) than the fact that users can't use their existing build > tooling. As you know, I think these are the right priorities to have. I agree on both counts. Still, it's nice that even with these compromises dgit manages to be much less a general purpose wrapper that other tools are. > Also in this area is the need for a way to do an sbuild on a git tree > which is not a fixed point under (or, even, representable by) > dpkg-source. There's a bug about that too. Yes. That one's really difficult. -- Sean Whitton
signature.asc
Description: PGP signature
