.. > My current understanding is that this only works if we agree that: > > * our packaging git can have all sorts of nasty stuff in it and > * the DFSG-clean thing is the orig tarball we dput into the archive with a > dsc
Yes, indeed these assumptions apply. I think these are accepted already. For example stuff uploaded to the NEW queue often exists in Salsa already and we don't gatekeep project-wide what is pushed to Salsa, but only what is pushed to the archive. > But with that view, my packaging git can never become the thing which we > consider "the thing Debian ships which honors the DFSG" and anybody who would > like to derive from us in a DFSG-compliant way still will have to use tarballs > when they want to import from us, no? The thing people end up consuming is the git contents as it is in the latest commit (or at a specific release tag). For all cases I am aware of when something bad existed in a git repo they were addressed by removing the bad stuff in new commits, not by purging (grafting) out specific files and regenerating the whole git commit chain, as it would invalidate all sha checksums and commit ids and thus also all release tags and signatures. In theory one could also delete the git data blobs that contained bad stuff, and leave the references, and just accept that git checkouts of certain old commits would reference unreachable objects and fail. That is however mostly a theoretic option, I don't recall any case where a copyright or security case would have actually required it in practice.
