Hello, On Tue 03 Jun 2025 at 11:08am +01, Ian Jackson wrote:
> As for our tooling and docs: > > * git-debpush should definitely reject a submodule. > That would have detected the problem locally. (clone -2) Yes. > * git-debrebase should detect upstream trees that have > submodules and call that situation a snag. (clone -3) Yes. > * Is there good tooling for doing DFSG-filtering entirely in git? > Eg is there some git tooling that will read uscan config? If you're using a merging workflow then you can delete the offending files once and then merging new upstream versions won't bring them back. But otherwise, no, this is best done manually at present, and it's a hassle. > * We need workflow manpages for tag2upload. Separately we want more > opinionated documentation of a git-first flow - that does not > involve gbp import-orig. We were just talking elsewhere about the problem of producing more and more documentation :) Unfortunately though I think you're probably right that we need another workflow manpage to write down things like "treat submodules as a +ds filter, i.e., like +dfsg". But how about we try writing the opinionated documentation first? I am slightly hopeful that would be enough and we wouldn't need a tag2upload workflow manpage too. > * I'm tempted to suggest an interim version of #726953 that makes it > possible to simply filter out submodules during canonicalisation. > > That would improve convenience when upstream has submodules but the > Debian package wants to ignore all of them completely. How common > do we think this situation is? > > (Note that it's easy to speak of doing this "as a quilt mode" or > "in quilt fixup" but it's not a "3.0 (quilt)" thing - it might > apply to native format source packages.) I would assume that it is not that common, but I don't know, we would need to ask people in packaging ecosystems that vendor a lot, presumably. -- Sean Whitton
signature.asc
Description: PGP signature
