Date: Thu, 28 Oct 2021 15:39:39 -0400
On Wed, Oct 27, 2021 at 4:16 PM Gamblin, Todd via SG15 <
sg15_at_[hidden]> wrote:
>
> - The operating system the thing was built for
> - Right now, this is really a proxy for system glibc version.
> - If we had more detailed provenance about libraries we could
> likely omit it.
>
> I want to pull on this thread a bit.
I think there's a bit that is being overlooked here. The glibc version used
is not a complete description of the dependency, because it presumes that
glibc will never drop versioned symbols that are only needed for older
binaries. RedHat has been communicating on their ABI guidelines that even
glibc should only be expected to be compatible across three major versions.
Likewise, while it's true that most Linux distributions have a
binary-compatible glibc, I don't think that assumption is necessarily going
to be true in the future.
For that reason, I think the requirement of encoding the specific OS where
the library was built *on* is not just a proxy for glibc version, but an
important record of what ABI stability is being promised by the vendors.
I think it becomes necessary to encode that more strictly, such that a
solver can reject a binary built on RHEL5 when trying to be consumed in a
RHEL8 box, for those that need to stay within the scope of what is formally
supported by the vendor, even in the cases where it would work.
Daniel
sg15_at_[hidden]> wrote:
>
> - The operating system the thing was built for
> - Right now, this is really a proxy for system glibc version.
> - If we had more detailed provenance about libraries we could
> likely omit it.
>
> I want to pull on this thread a bit.
I think there's a bit that is being overlooked here. The glibc version used
is not a complete description of the dependency, because it presumes that
glibc will never drop versioned symbols that are only needed for older
binaries. RedHat has been communicating on their ABI guidelines that even
glibc should only be expected to be compatible across three major versions.
Likewise, while it's true that most Linux distributions have a
binary-compatible glibc, I don't think that assumption is necessarily going
to be true in the future.
For that reason, I think the requirement of encoding the specific OS where
the library was built *on* is not just a proxy for glibc version, but an
important record of what ABI stability is being promised by the vendors.
I think it becomes necessary to encode that more strictly, such that a
solver can reject a binary built on RHEL5 when trying to be consumed in a
RHEL8 box, for those that need to stay within the scope of what is formally
supported by the vendor, even in the cases where it would work.
Daniel
Received on 2021-10-28 14:39:50