These are all really good points. The thing we have struggled with here is what is “the OS” — there is often not just one configuration of an OS, and it’s hard to pick a good identifier or ABI version for it. We currently use this library on Linux: https://github.com/python-distro/distro
which gives us identifiers like ubuntu18.04 or rhel7. Sometime people expect that to mean that some default package is installed that actually isn’t in, say, the base image.
That is yet another thread, I think, which is the ability to describe OS packages even when we are running a package manager on top of the package manager. e.g.: I built against the glib2 package on RHEL7.6
I guess if I had my way, the vendors would publish a set of rules or something that say what ABI guarantees they’re promising *in terms of* core libs*
I think coarse rules like “RHEL5 binaries can’t be consumed by RHEL8” are kind of hard to maintain because the reason for them gets lost in the vagueness of the OS identifier.
The rules are actually much more specific than that, at least for RedHat. In that case you can actually look at `objdump -p` on the executable, and as long as you know the origin RHEL major/minor version where it was built and where you are, and you'll be able to tell if it's formally supported as ABI compatible (although lots of things continue to work beyond that).
The other way the OS identifier is vague is that sometimes you may build on a particular OS, but with a completely different user land stack.
Hmm. I'm afraid that's pointing to the fact that we need to model it all the way down, so I guess we also need to be able to generate the data from the OS packages... It probably also means that folks doing package management would need to model improperly-packaged libraries too.
This makes me think we need to have a reasonable fallback process for the simple cases.