Roger Leigh <rle...@codelibre.net> writes: > I can see that this could be a legitmate cause for concern, especially > since the history is essentially immutable and if "tainted" will remain > so unless it's deliberately excised and the history is altered. > However, is this a problem in reality, or just theoretical?
It's definitely a real problem for some packages provided that we stick with our rules about what's okay for Debian main in source packages. For example, the openafs Git repository history contains APSL-licensed code that's not okay for main. > If it's only a problem occasionally, then could this be better dealt > with (with the cooperation of upstream) on a case-by-case basis as and > when this becomes a real issue? Upstream is not going to be willing to run git filter-branch to remove things from their repository and invalidate all clones. It's frequently a challenge just to convince them to remove non-DFSG code from their releases. So if you're merging with upstream's Git tags as part of packaging, which is very nice for other reasons, you'll have this problem. > I'm not a fan of shallow clones due to the loss of history--we're losing > out on the main advantage to having a git repo at this point. I'm not > an expert WRT shallow clones, but can you get back to a full clone given > the packaged repo? Yes, if you have access to the full repository. >> Joey would really rather upload his whole repository for things that he >> knows are clean, but that's a problem for ftp-master review, and you >> have to get into who you trust to make that determination. > If I tag a debian release in my repo and sign it with my Debian GPG key, > it should be possible to "upload" the new source package to Debian with > a "git push" (or upload a small .dsc and get the a central git repo to > do a pull from me). It should all be properly verifiable from our GPG > web of trust. Maybe best restricted to pulling from git.debian.org or > just pulling a single signed tag? That's not the problem being discussed here. The signature is fine. The problem is that while Joey may think that his repository is completely DFSG-free, it's the current job of ftp-master to actually check that. For a complete repository, that's a lot of work. Should ftp-master just trust Joey that there's no non-DFSG code anywhere in history? Who should be trusted? We get into very murky ground here, which is much different than the current review process. >> Best practices for Git repository layout? >> - git-buildpackage documentation is closest to that > I would have to disagree here, the git-buildpackage default layout is > far too "Debian-centric". What this note meant was that it's the only one that anyone has written down that anyone in the room mentioned. If you have a better best practices guide, by all means advertise it! There was some interest in seeing those. > This is something to think about for the future though; dropping binary > uploads (by maintainers, not buildds) has been on the cards for some > time now hasn't it? Is this still planned? Did it ever reach the point of being planned? > Essentially, *everything* stays in git from upstream to distributed > releases to debian work and releases and also to downstreams. There's > no import of release tarballs because they are in git too, and there's > no pristine tar because the GPG-signed tag of the distribution *is* the > release. Currently what an upstream releases as the tarball might not > exactly match the release in the VCS (due to autotools bootstrap, other > generated files etc.) so here "make dist" actually makes a separate > "distribution" branch (as opposed to release) so you have a natural set > of branches: > development → release → distribution → debian →→ downstream > and at each step you have GPG-signed tags giving you an auditable > chain of trust along the path. Does any upstream do that yet? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqxjr0k5....@windlord.stanford.edu