Simon McVittie writes ("Re: Include git commit id and git tree id in *.changes
files when uploading?"):
> It isn't clear to me whether our rules impose sanctions on maintainers
> who allow non-Free files to become part of the packaging git repo
> history,
We do not impose any such sanctions. Best practice is to not attempt
to DFSG audit the git history.
Our advice in eg dgit-maint-merge(7) is to "git rm" nonfree things to
make a DFSG-free branch. There are other approaches, with roughly
equivalent effects: namely, we're confident the nonfree (or
possibly-nonfree) files don't end up influencing distributed binaries
we can't accidentally rely on them, and they don't show up in normal
work, but we still get all the benefits of using upstream history.
This approach is only appropriate when the files aren't legally
dangerous.[1] If they are then we obviously need to take stronger
measures, perhaps involving git-filter-bramch, or disregarding
upstream git entirely. But, legally dangerous files are pretty rare
in published upstream git histories for obvious reasons.
In the 12 years we've been running dgit-repos, we have never been
needed to launder an existing git repo for legal reasons. Presumbly
it will happen at some point. We've had to rewrite things on one
occasion because of a bug that generated corrupted git objects. So,
we do have a plan for it, including safeguards that can prevent
reintroduction of cursed git objects.
> If your goal is to have all packages in Debian be based on their
> upstream VCS history, then I think the "history contains non-Free
> things" and "history contains unnecessary, large things" cases will need
> to be addressed somehow, either by declaring those to be situations
> where the upstream VCS history cannot be used, or by having those
> situations be specifically allowed by someone who can speak on behalf of
> the project.
We've been including non-free things in git histories on Alioth,
dgit-repos, and Sala, for many years now.
As one of the DPL-Delegated service operators of dgit-repos, I can
confirm that it is our policy that this is OK. Will that do? :-)
git histories containing things that are far too large are a potential
problem, indeed. I don't know how common this is. So far we have
generally got by (as a project) with ad-hoc answers.
> I'm sure some Debian contributors would say "if your upstream has been
> imperfect in the past, you should simply never have packaged that
> software" but that doesn't seem like a way to continue to have a
> complete and useful operating system, especially wnhen the position where
> we draw the line between Free and non-Free changes over time.
Quite so.
Ian.
[1] By "dangerous" I mean consequences for handling the files
which are worse than merely being asked to stop distributing them.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
