I'd note that I don't see "rethinking target tuples" as changing how any given name is assigned, but rather changing how they are defined and how they are thought about.
We wouldn't break anything by changing the fourth field to mean "Environment" rather than "Operating System", to be more well-defined - every existing tuple would still be the same, and even some existing erroneous ones would be validated rather than existing in a state of being incorrect, but impossible to change. Any tuple with `elf` as the final component, for example, would be correct as an Environment, not as an Operating System, and now those existing tuples would be sound, and not just "hanging on because things break if they cease to exist". On Sun, 10 Sept 2023 at 20:56, Po Lu <luang...@yahoo.com> wrote: > "Zack Weinberg" <z...@owlfolio.org> writes: > > > I haven't been following this long discussion very closely but I do > > have some opinions (with my "de facto autoconf maintainer" hat on): > > > > 1. As a general rule, it is not safe to change the canonicalization > > (i.e. the config.sub output) of an existing system name, *at all*; in > > many cases, not even if it is wrong. I find that people working on GNU > > tools often don't realize just how broadly used these names > > are. Changing the canonicalization of "CPU-VENDOR-mingw32", for > > example, is very likely to break things like Ansible playbooks and > > Travis-style CI build matrices -- one-off files that exist by the tens > > of thousands and there's no practical way to *enumerate* them all, let > > alone get them all changed to satisfy a GNU-internal desire for a more > > consistent naming convention. > > > > *Very recently introduced* names can be adjusted to correct technical > > errors. For example, "CPU-VENDOR-windows-gnu" is a misnomer IMHO as > > there is no GNU libc port to Windows (see below); config.guess should > > not produce it and config.sub should not convert anything into it. > > But if the patch that had introduced this mistake were more than a few > > months old, we would be stuck with it, permanently. > > This mistake is only two months old, thankfully. I believe it can be > corrected without consequence. >
