Ian Jackson <[email protected]> writes: > Simon Josefsson writes ("Re: Include git commit id and git tree id in > *.changes files when uploading? [and 1 more messages] [and 1 more messages]"): >> Ian Jackson <[email protected]> writes: >> > in a "friendly low-complexity upstream" case when 1) debian/gbp.conf has >> > upstream-vcs-tag and 2) debian/watch points to upstream git? Assume we >> > don't have to care about debian/copyright Files-Excluded and other >> > complexity that doesn't hold for >50% of packages. >> >> With those limitations, I don't think the attack you describe works. By >> having 'gbp import-orig' import verbatim pristine git from upstream, you >> avoid the hard-to-audit upstream tarball. Or can you describe how >> things would go wrong in that setup? > > Thanks for the reply. I think I was probably wrong there: > > I was going by what I saw in uscan(1)'s DESCRIPTION section, which > mentions only tarballs and doesn't talk about getting information from > the VCS. But now that I search it for "git" I see the `mode=git` option. > > Based on what I read there I now think you are right and I was wrong, > assuming by "debian/watch points to upstream git" you mean using > "mode=git" in debian/watch. [1]
Great, I thought I was missing something. > The description in uscan(1) says in this mode it will always *make* a > tarball. Specifically, it says it "packs the source tree" which I > assume means git-archive. (Does it in fact use git-archive? I think > we would want it to, to include the commitid metadata in the pax > header extension. I don't see any reason why it *wouldn't* use git > archive.) So yes that would avoid the hazard I'm talking about. Using git-archive to get the commitid stored (and maybe .gitattributes, which will break the entire argument again...) ought to be a bug report if uscan doesn't do that already. > And then, my reading of gbp-import-orig(1) suggests that this will > indeed include the upstream history, as desired. I don't think gbp import-orig unconditionally uses uscan, doesn't it use origtargz? Which adds more complexity to this. I recall getting a *.orig.tar.gz from uscan and a *.orig.tar.xz from gbp, or vice versa. > I note that the uscan(1) manpage discourages the use of mode=git. > That seems like bad advice to me. The warning seems dated to me. I think there are good arguments why we should use upstream git source code rather than 'make dist' tarballs, although I think you are in the 'use sources from git clone' camp and I find myself more in the 'use sources from git archive' camp due to .gitattributes. These camps are close though, and the real (xz-)problem is the 'make dist' variant and not git-clone vs git-archive. > So now ISTM that this combination of configuration would work fairly > well. But I haven't tried it out - I'm just going by the > documentation. I guess if you do this gbp import-orig will make a > null delta commit to represent the nonexistent diff between the > uscan-exported and gbp-reimported tarball tree, and upstream git. But > that's probably harmless. If there is no delta, there is no extra commit. This is the normal case for 'gbp import-orig' in my experience. > I'm not sure why this is *better* than gbp import-ref, though? > That is, you could use uscan mode=git and gbp import-ref. > That would presumably omit the anomalous null delta import commit. Indeed -- and I would go further and not even suggest 'gbp import-ref' but well-known standard git commands like the ones I suggested. However, and there is some value in this, Otto suggests that 'gbp import-orig' should be a standard idiom that any maintainer can use to import upstream sources. I think he has a point. My goal here was to get both of to get what you want at the same time, and with some clever configuration (debian/watch uses git and gbp uses upstream-vcs-tag) this seems possible. I'm pretty sure someone will find this configuration a deal-breaker though. <rant>I like dgit and GBP, but the complexity is awful, and the only forgiving thing for me is that I've (barely) managed to learn them and has now invested in that knowledge. There is no reason (except legacy) why one shouldn't be able to work with pure git and simple configuration files to package something for Debian. The Debian tradition to wrap tools in wrapper tools in wrapper tools in wrapper tools is exhausting.</rant> /Simon
signature.asc
Description: PGP signature
