On Wed Nov 27, 2024 at 4:30 AM GMT, Otto Kekäläinen wrote:
> 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 was really surprised to receive this feedback. I agree with using
intentional language and not denigrating other's work. I spent a few
days reflecting on what I wrote and how you've responded to it, and I
haven't come to a conclusion as to whether I agree with you or not. On
the one hand, juxtaposing "not good" with "gbp" could be taken badly,
and using something like "not correct" or "not appropriate" may have
avoided that; on the other, I believe I was clear in expressing that I
was talking about the software's defaults rather than the software
itself.
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.
Presently I prefer not to use gbp, so I don't think this would be an
efficient use of my time. I'm also undecided on whether gbp should be
recommended as the default tool that we recommend to developers for
managing packages. I feel that engaging with your efforts on DEP18,
considering how to progress DEP14 and the related discussions on -devel
are a better use of my resource at the present moment.
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)
Please don't infer the answer to "does upstream have tarball releases"
from "pristine-tar true/false", as they are not the same thing. I'm sure
there are packages repositories where upstream's tarball is ignored, a
"git archive"-produced tarball, or a GitHub release-derived tarball, is
used instead, *and* the pristine-tar branch duly populated (which again
is independent from whether the maintainers have provided a
debian/gbp.conf with a pristine-tar key value in it.) Likewise there are
package repositories where the packaging is based on an upstream tarball,
but pristine-tar is not used, and/or its use not documented in a
debian/gbp.conf.
More generally I think the *right* place for much of this metadata is
not gbp.conf but should be somewhere more tool-agnostic, at least unless
we actually agree to elevate gbp to the status of "use this unless you
have a very good reason not to".
--
Please do not CC me for listmail.
👱🏻 Jonathan Dowland
✎ j...@debian.org
🔗 https://jmtd.net
