I feel like positions are becoming entrenched, so let’s see if I can move things forwards.
I think we all agree that something needs to provide more specific guidance for wheel creators about compatibility than “Linux distros with glibc >= 2.x”. At a minimum, we want auditwheel to do this in the form of “here’s a wheel, is it compatible?”
Is it useful on top of this to have the rules auditwheel uses documented somewhere, whether we call this a specification or something else? It seems that the answer should be a clear yes, so long as it’s not an undue drain on resources and we’re confident we can keep it up to date.
So, can we keep it up to date without expending lots of effort on it? For the library and symbol lists in auditwheel’s JSON profiles, I imagine it wouldn’t be hard to autogenerate some human-readable documentation, so there’s a single source of truth (this is an idea @zwol proposed on the perennial PEP PR). Other specific rules encoded in auditwheel’s code are hopefully changing slowly enough that we can easily maintain written details by hand.
Would people be happy with partially-generated documentation living at e.g. https://packaging.python.org/specifications/ ? This would, I think, involve less effort than writing a PEP for each profile.