[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: