Re: How to handle ABI breakage in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Robert Relyea:

> On 12/6/21 7:11 PM, Kevin Kofler via devel wrote:
>> Florian Weimer wrote:
>>> That's not actually true, though, and it does not make much sense.  If
>>> upstream commits to an ABI, versioning is not even required technically.
>> Hardly any upstream actually commits to an ABI *forever*. Even if the ABI
>> has not changed for 10 years, that does not mean that at some point a new
>> ABI will not be implemented. Even glibc has a soversion (which has not
>> changed for years, but it has one).
>
> Upstream NSS commits to changing the major version number (which is
> included in the library name) if it were to change the ABI. ABI breaks 
> are fixed upstream when they occur, and there is a CI abi scanner
> which runs on all upstream commits to identify ABI issue. The current
> ABI has been stable for 2 decades now.
>
> I don't know of any other package that maintains that level of
> commitment.

There were/are issues around the size of global data:

  using the external array SSL_ImplementedCiphers[] directly should be
  deprecated
  <https://bugzilla.mozilla.org/show_bug.cgi?id=1201900>

  Add accessor functions for SSL_ImplementedCiphers
  <https://bugzilla.mozilla.org/show_bug.cgi?id=496993>

ELF targets with copy relocations do not allow shared objects to change
the size of exported symbols.

(I have a build of GCC 2.7.2.3 from December 1998 that still works, but
to some degree that's easier: it's just turning one text file into
another.  Admittedly I had to fix a glibc regression likely probably
before 2000 to get them working again.)

But my point is that the rule about soname versioning seems overly
strict.  Downstream-specific sonames are very poor substitute for
upstream ABI management.

Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux