On 08/17/2014 12:20 AM, Russ Allbery wrote: > Thomas Goirand <z...@debian.org> writes: >> On 08/16/2014 07:05 AM, Jeremy Stanley wrote: > >>> However upstream may build tarballs through a (hopefully >>> repeatable/automated) process at release time, publish checksums and >>> signatures for them, et cetera and prefer packagers use those as the >>> original tarballs for official release versions. > >> And then? If I prefer to use their git repository, and create my own >> orig.tar.xz out of a signed git tag, what is the problem, as long as I >> use the tag they provided by upstream? > > Suppose someone wants to check (possibly as part of a forensic > investigation) that the source in Debian matches the source released and > signed by upstream. If you reuse the upstream tarball, the signature is > valid, so this is as simple as verifying the Debian *.orig.tar.xz file > against the upstream signature or a checksum of a good copy of the > upstream source. If you regenerate the tarball, those checksums are no > longer valid, and now someone has to unpack both tarballs and compare all > of the files (and, depending on what they're checking, permissions and > other metadata) individually. > > It's not a huge advantage, but for me at least it's a quality of > implementation issue to base the packaging on the tarball as released, > instead of on a tarball generated from the same file tree.
But then in which way will you check that the said upstream tarball, without any upstream checksum, is valid? At least tags are signed... Also, why the forensic investigation wouldn't instead check that the generated tarballs are really based on the correct PGP signed tags? >> And often, upstream include in the tarball artifacts which we do not >> need, like generated files and so on. > > This is true, and opinions differ about the tradeoff there. I personally > prefer to upload the source as released by upstream, including those > artifacts, to Debian, because I don't know how people who pull the source > from Debian might want to use it. Yes, *we* don't need those artifacts, > but maybe someone wants to do an apt-get download and then run ./configure > and make for some reason without using the Debian packaging. > > Basically, I see no harm, only a small amount of additional work once > pristine-tar and git-buildpackage are set up properly, and a moderate gain > to basing packaging on the upstream tarball as released. I also do this > for packages for which I'm upstream. As Charles wrote, pristine-tar works with small tarballs, but when upstream has multi-megabytes tarballs and releases often, the Git repository quickly grows to something not manageable. On 08/17/2014 01:08 AM, Michael Biebl wrote: > More importantly (at least in my experience): If you are working in a > team and you regenerate the tarball from git, it's very likely that > the md5sum of the generated tarball differs from what has been > uploaded to the archive by a different team maintainer in a previous > upload, resulting in a reject by dak. Yes, that's a problem. Though it's easy to download what's been previously uploaded to Debian before the final upload. At least easier than downloading 293874 old copies of past released tarball in the pristine-tar branch. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f065d2.5050...@debian.org
