Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
> > Charles Plessy <plessy@debian.org> writes:
> >
> > > Also, it is very sad that, as a project, we can not decide whether we go
> > > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > > from the people whose work is direclty impacted by the use of this
> > > format.
> >
> > We know what a primary concrete objection is. We discussed it at length
> > at DebConf two years ago, and then on debian-devel afterwards. Uploading
> > a Git archive requires reviewing the entire contents of the archive, not
> > just the current code, for licensing issues, which is pretty painful from
> > the ftp-master perspective.
>
> How come? If the .git directory shipped in the package is pruned, there is
> no hidden data. All you have to review are commits that are present there,
> which is exactly the same as with quilt: you need to review the tarball and
> every single patch.
I think this is a key point. The aim of the git format should not be
provide the entire history, any more than the other formats do (not).
What should be provided needs to be
- sufficient to build the package
- sufficient to determine the changes made between the Upstream
release and the Debian upload
- sufficient to allow further uploads, including NMUs
- (allow restoration of the full history)
> > There was never really a satisfactory resolution to that discussion. We
> > can upload very shallow clones, but they end up looking a lot like the
> > existing quilt format with single-debian-patch,
>
> There's a whole world between shallow clones and complete ones. While
> existing git porcelain provides no convenient tools to selectively
> shallowify a repository, this is because no one had that need before.
>
> If we allow non-linear Debian changes (ie, merged not rebased, etc), there
> is indeed a complex question: where to cut[2]. But even then, a given commit
> is either present or not. If too much old history is there, that's no
> different from the upstream shipping an old tarball and a pile of patches
> upon it (like ancient apache or qmail).
If the git repo contain two tags, maybe signed, one which uniquely
referenced the upstream version, and one which referenced the debian
version, then all commits not part of the graph between these two
commits could be dropped. This would preserve all history of
branching and merging between these two points. Tools used for
importing upstream tarballs could automatically create such tags;
native git projects can do this themselves. These tags could be
put in the .dsc, so that projects can use their own naming rules,
or dpkg-source could use a specific method. [As an upstream who uses
signed tags for all releases, the flexibility to use the project-
specific tags would be useful.]
dak could check that the upstream tag referenced the same commit
between uploads, as well as maybe also verifying the tag signature.
This would ensure that the upstream source couldn't be altered in
an upload, the same as is enforced for orig.tar right now.
dak could also check the debian tag if required; though the .dsc
signature would presumably be sufficient, signed tag verification
would be useful for a potential git-only workflow in the future.
Providing that the packaged repo contains links to the public
git repo, and we can get this from debian/control (in case the
developer is using a private or git+ssh repo), the end user
should be able to do a simple "git fetch origin" to restore the
full history.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: