Re: Notes from the DebConf Source Format BoF
Roger Leigh <rleigh@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: