"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.
