Hi! On Mon, 2025-01-06 at 16:45:54 +0100, Simon Josefsson wrote: > Santiago Vila <sanv...@debian.org> writes: > > Note for Guillem: I've included your suggested fix in the bug template.
Great, thanks! > I don't think we should patch upstream code for things that aren't clear > upstream bugs. Patching upstream code in Debian packaging has a > maintainance cost and some risks. I disagree. Regardless of this being an upstream bug or not, I think patching should and has always been an option, if it improves our lives, or gives better behavior when integrating with the packaging. Integration into a distribution implies potentially making different trade-offs, which are not necessarily upstream bugs. > As far as I understand, the reason > for the FTBFS's isn't due to upstream misuse of gettext, it is a symptom > of how Debian packaging is (mis-)using autotools. While an upstream would not usually see this particular issue, unless running autoreconf on an already autoreconf'ed tree during development (for example), the semantics for AM_GNU_GETTEXT_VERSION might seem to give some sense of control, but at the same time these seem counterproductive, in a similar way as if a project requested that it needs an exact version of any other tool (when a minimum would work as well and give users an easier time), notice how this behavior diverges from for example autoconf's AC_PREREQ which only requires a specific minimum version. This seems like a recipe to ship obsolete build system infrastructure, so in that sense it still looks like something worthwhile I'd still propose upstream. > In this case, I don't think filing upstream bugs is a good idea: it > seems more appropriate if we fix this via debian/rules instead of > putting fixes to Debian-specific problems into upstream code > (especially since the fix changes upstream semantics wrt gettext so > isn't guarantee to be what upstream prefer). Some of the packages > seems to already do strange things in debian/rules related to gettext > and autotools, so I think at least some of these are packaging bugs > and not upstream bugs. Personally I think using AM_GNU_GETTEXT_REQUIRE_VERSION is the better fix (both for upstream and for our packages), as it gives better semantics, and should reduce workarounds, hacks and hardcoding of internal gettext details from debian/rules, and simplify packaging, with the cost of a few lines patch. Potentially forcing a version mismatch via debian/rules seems more error prone, and it also means going against the wishes of the autotools upstream which added those version consistency checks for a reason. :) Of course upstream projects might reject the patch, but then I also think it's perfectly fine to still use the simpler, more robust and elegant solution at hand, regardless. And as long Debian considers best practice to run autoreconf at build time (even if it's currently imperfect, so that we can regen stuff if we need to modify the autotooled build system source, or get new autotools changes percolated into the whole archive with a mass rebuild), maintainers should feel free to use the best tool at hand to support that. Thanks, Guillem
