Date: Thu, 28 Oct 2021 16:49:39 -0400
On Thu, Oct 28, 2021 at 4:30 PM Gamblin, Todd <gamblin2_at_[hidden]> wrote:
> 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.
>
RedHat, in particular, does that:
https://access.redhat.com/articles/rhel-abi-compatibility . It is true that
it would be much better if all vendors did the same.
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.
> 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.
>
RedHat, in particular, does that:
https://access.redhat.com/articles/rhel-abi-compatibility . It is true that
it would be much better if all vendors did the same.
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.
Received on 2021-10-28 15:49:50