Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

[Petr Pisar]

On Thu, Jul 02, 2020 at 10:35:27AM +0200, Vít Ondruch wrote:
>  I just met something which might be of similar nature. Recent FF
>  78.0-1.fc33.x86_64 fails to start with older glibc:
>  
>  
>  ~~~
>  
>  $ firefox
>  XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
>  /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
>  version GLIBC_2.32
>  Couldn't load XPCOM.
>  
>  ~~~
>  
>  
>  Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
>  glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
>  issues like this are unexpected. There should be something, what would
>  force glibc update if FF requires more recent one.
>   
There is nothing like that. This issue is not specific to glibc. If a library
adds a symbol, it does not have to bump its soname. Thus on RPM level there
won't be any change. If another executable starts using the new symbol, there
won't be again no change on the RPM level. Therefore RPM finds a match at
installation, but the dynamic linker finds a dissonance at run time.

ELF RPM dependency generator could promote these linker symbol dependencies to
RPM level, but I worry that most people will complain about growing YUM
repository metadata.

I don't think it's realistic to expect from the packagers that they will check
and add these new dependencies manually. Teoretically, rpminpsect run in CI
could catch these changes and warn the packager. But I worry that many people
won't understand it and just keep ignoring it.

-- Petr