Re: aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT

[Carlos O'Donell <carlos@redhat.com>]

On 04/19/2018 01:06 PM, Szabolcs Nagy wrote:
> if these paths are for optimization only then i guess the list
> can change between libc releases without causing issues other
> than performance regressions.

There is a "full lifecycle" cost to turning on multilibs.

In RPM transactions the new libraries are installed and then the old
libraries are removed.

This means that you can have an old multilib'd library present in the
middle of the install, and if you are deprecating the multilib, the
remaining library will be the old one, it may be loaded, and may not
work correctly.

Consider this case:

* Add lse/ search dir if 8.1 LSE.
* Deploy multilibs.
* Deprecate multilib because performance is good enough by default and
  you want to stop paying for the build/test/qe costs of two builds.
* Remove multilibs.
 
At this point all multilib'd packages must deploy a "<package>_post_upgrade"
application which erases all known multilib'd files to avoid loading a
mixed lse/ library with a newer set of libraries. We do this in
glibc via glibc_post_upgrade.c in Fedora [1].

One alternative is to deprecate the lse/ search dir immediately in ld.so,
which is not always desirable because some applications may still be
relying on it to load/operate correctly.

So think carefully before turn on multilibs. The additional verification
and deployment costs should not be ignored.

As a reference, presently in Fedora for POWER we have 4 x ppc64be multilibs,
and only 1 x ppc64le multilib. This is relatively under control because the
ISAs are nested well and Fedora has all POWER8 builders (the latest multilib).

-- 
Cheers,
Carlos.

[1] https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc_post_upgrade.c