Quoting Zack Weinberg (2023-08-18 04:42:32) > On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote: > > ... such blunders should be ignored, or at least normalized... > > Even more important than this is the principle that config.sub canonical names > are *never* changed, even if they are wrong according to some external > standard.
The stability of the set of accepted triples is precious to me as well. However the patch in question [1] was applied [2] less than seven days after it was submitted. It is a bit unfair to quash Po Lu's concerns simply because he happened to be on vacation that particular week. Perhaps it is time for GNU config to tag releases? This could be done near-automatically: every three months a release-YYYY-MM-DD tag is added to the then-six-months-old HEAD, provided that no objections have been raised. This would allow the current prompt application timetable (which prevents merge conflicts) to continue. Note that most large distributions upgrade the `config.sub` vendored by their upstream packages: GNU Guix: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/check.scm#n561 Void: https://github.com/void-linux/void-packages/blob/master/common/hooks/pre-configure/01-override-config.sh nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/update-autotools-gnu-config-scripts.sh Guidance as to which GNU config commit to use would be appreciated. "Just use the latest commit" puts stability in conflict with merge conflict management. "Use the latest release-YYYY-MM-DD tag" would avoid this conflict. - a [1] https://lists.gnu.org/archive/html/config-patches/2023-06/msg00005.html [2] https://lists.gnu.org/archive/html/config-patches/2023-07/msg00000.html
