Hi, (replying in one email to various comments in past 24h)
> How common debian/gbp.conf points at something else: perhaps gbp's > defaults are not good, if that many packages need to override them. First of all may I ask you to not use terms like 'not good' as it may come off negative towards the maintainer of that software. Guido has done an amazing job with git-buildpackage and we certainly want him to continue iterating on it. I also suggest you to participate in gbp development, as currently it is 95% Guido alone. At https://salsa.debian.org/agx/git-buildpackage/-/commits/master you can for example suggest changes to those defaults along with a migration path, or you can help with just improving the documentation so people more easily end up choosing the right options. Secondly, it is perfectly valid for evey single package to have a debian/gbp.conf and I would in fact prefer that. For every upstream we need to have metadata on: - do they have tarball releases (pristine-tar true/false) - do they have git tags and what is the format (upstream-vcs-tag) - are those git tags expected to be signed or not (upstream-signatures on/off) If a package maintains stable releases or backports or Ubuntu versions, or if upstream has multiple lines of parallel major version releases each branch also needs a debian/gbp.conf to tell what are the correct settings for that branch. > > Until we record expected upstream tarball hashes in a debian/* file, an > > acceptable approach seems to be to skip the pristine-tar branch and be > > sure to download the previous orig.tar.* + orig.tar.*.asc from the > > Debian archive, instead of attempting to re-generate it from the > > upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible). > > This is 1). It cannot be done generically as it requires knowing > where to download from, etc. > > > I have never understood what value there is in duplicating the uploaded > > tarball in the git repository. Recording a hash of it is sufficient. > > The hash is sufficient for knowing it changed, but you still have to > get the actual tarball from somewhere. Don't we have uscan in all packages? If would be nice if https://codesearch.debian.net/ supported searching just the existense of files so one could check this out quickly. The way most other Linux distros do this is that they have sha256 sums in the package definition, and a url where to download upstream tarball from. In Debian we have debian/watch for the latter, but no sha256sum to verify the exact version. We could, if we want, introduce for example a new file debian/source/origin which could automatically be updated by uscan to have the exact url and sha256sum and the maintainer just needs to commit it after running uscan to import the upstream sources. However it will take years to design and agree on a new file and have it in the policy and roll it out. The good thing with git-buildpackage is that we have it already, thousands of packages uses it, and it works well and is fully capable of producing the source files consumed by dpkg-buildpackage etc to build the package. > > > One possible rebuttal to this is "gbp needs to do the right thing then". > > > Currently gbp by default generates a broken tarball, which is also a > > > source of confusion for many. > > > > Do you have a bug report number? > > No. > I've found #902249 which is titled "Pull tarballs from the archive (or > upstream location)", maybe that's the one you think about. I haven't read > it, except for the "I hoped we could stay out of that business in 2018 but > since tarballs are still _the_ _thing_ in Debian" line, which I liked. > > For the avoidance of doubt, I don't think gbp *can* do the right thing > there. It's not my rebuttal. Maybe gbp should just refuse to generate a > random tarball from a commit-ish and let^Wrequire people to provide one or > provide a way to generate one in a correct way. I often hear this complaint about pristine-tar, but I don't take it seriously until somebody actually files a bug report and has a reproducible case. For every single package I maintain I use pristine-tar and it works correctly. Personally I try to leverage upstream signatures both for tarballs and git tags as always when available, and for tarballs it requires pristine-tar, so I would not stop using pristine-tar as long as it works.
