Changes/GLIBCALT

Installing a new GNU C Library

Summary

As outlined in the [Interface] document, there is a need by developers to be able to install a newer version of glibc for use with newer ISV binaries, or to access newer interfaces. The newer alternative glibc is provided via a parallel install. Important in this design is that all existing builds continue to use the default system glibc-devel. Developers must take active steps to compile against glibc-alt-devel. Lastly the system can be switched to run with the new glibc-alt, again without impacting how applications are built by default. This requires a new glibc-alt package, which has much shared with the glibc package.

Owner

• Name: Carlos O'Donell
• Email: carlos@redhat.com
• Release notes owner:

Current status

• Targeted release: Fedora 29
• Last updated: 2018-07-09
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

A new package glibc-alt is created with the following packages and subpackages:

• glibc-alt - The new glibc, installed into /opt/glibc-NEVRA/, with sysroot beneath that package.
• glibc-alt-common - Likewise.
• glibc-alt-devel - The required development files installed into /opt/glibc-NEVRA/.
• glibc-alt-static - Likewise.
• glibc-alt-headers - Likewise.
• glibc-alt-locale-source - Likewise.
• langpack-* - Provides new language packs for glibc-alt.
• glibc-alt-all-langpacks - All language packs in one archive.
• glibc-alt-minimal-langpack - Minimum language support.
• nscd-alt - New version of nscd.
• nss_db-alt - New version of nss_db.
• nss_hesiod-alt - New version of nss_hesiod.
• nss-devel-alt - New version of development files.
• glibc-alt-utils - New version of utility files.
• glibc-alt-debuginfo - Debug information.
• glibc-alt-debuginfo-common - Debug information for common files.
• glibc-alt-benchtests - New microbenchmarks.

The filesystem layout will all run through a single symlink to switch between the normal version of glibc and the alternatives.

• /opt/toolchain/glibc [Will be the system default and a symlink]
• /opt/toolchain/glibc-NEVRA [Will be the various installed versions including the one which defines the GA for the release].

The alternatives system will set the /opt/toolchain/glibc symlink to point at the appropriate glibc-NEVRA, and it will never select the glibc-alt version by default, it will always require a conscious change by the system administrator.

Developers using glibc-alt will use a combination of compiler options including but not limited to --sysroot to specify that the application is being built against the new version of the development files and headers. Normal builds will simply continue to use the default system headers and libraries.

Once the new glibc-alt is selected by the alternatives system all new processes that start will be using the new glibc-alt and the new data that this glibc provides. This can mean that some processes may fail to start if they were started just before the symlink switch and ended up with a old runtime but new data files e.g. locales. This is no different than today, but the race is actually narrower with this system.

This discussion to install glibc-alt, while in the context of a Fedora install, need not be carried out on the developers primary system, this can be done in a VM or in a container, and all the same benefits apply but with better isolation from the development system. At the same time the developer retains the component versions in the rest of the system, upgrading only glibc.

Benefit to Fedora

The benefit to Fedora is that users that need to upgrade their glibc can do so without impacting the rest of the system packages and how they are built. Fedora users can install a new glibc in a VM, or in a container, and use that distinctly from their system without impacting system behaviour.

Scope

• Proposal owners:

• Other developers: N/A (not a System Wide Change)

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
  • List of deliverables: N/A (not a System Wide Change)

• Policies and guidelines: N/A (not a System Wide Change)

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No
• Blocks product? product

Documentation

N/A (not a System Wide Change)