On Tue, Nov 26, 2024 at 10:31 PM Otto Kekäläinen <o...@debian.org> wrote: > > 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)
I'm not really following this thread, but I sincerely hope you aren't suggesting that every package in Debian have a gbp.conf file. (I don't think you are on closer inspection, I think you mean that it's valid for every package *that uses gbp* to have a config file.) I very intentionally don't use it (it has its place, but for the packages I work on it is overkill and greatly complicates my job as a developer with very little payoff), and have no desire to use it. If it was to be made mandatory for all packages, in all likelihood I would comply, but I would not be happy. This isn't to lambast gbp at all - like I said, it has its uses. It just doesn't have uses for me, due to a mixture of my needs and my preferences. (Off-topic, but part of the reason I don't use gbp is the docs for how to use it are just not enough to actually figure out what you're doing. Just a documentation revamp or initial tutorial for it would be awesome. Maybe if I ever relearn it I should help with that...) -- Aaron > 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. >
