Removal of the glibc-headers package
glibc-headers.x86_64 package with a
glibc-headers-x86.noarch package, and merge
glibc-devel on the other architectures.
- Name: Florian Weimer
- Email: firstname.lastname@example.org
- Targeted release: Fedora 33
- Last updated: 2020-07-21
- FESCo issue: #2371
- Tracker bug: #1828332
- Release notes tracker: #499
It was always the intent that on Fedora for x86-64, only the
glibc-headers.x86_64 was installed and available from composes. However, due to compose tool limitations, the
glibc-headers.i686 package sometimes leaks into the compose, and end users may install it, causing future upgrade problems.
glibc-headers.i686 is installed for some reason and it vanishes again from the compose, the system cannot be updated anymore using
We cannot remove the
glibc-headers.i686 package from the build because the i686 buildroot needs it. The current solution is to provide a
glibc-headers-x86.noarch package on i686 and x86_64. Since it is a noarch package, the existing compose tool is no longer a problem.
(For s390x, we may or may not do the
glibc-devel merge; this depends on whether some people are still building the
glibc.s390 package locally.)
releng issue #8337 contains further background information.
Benefit to Fedora
System upgrades will work more reliably.
- Proposal owners: Implement the glibc changes and remove some of the build dependencies on
- Other developers: Help with the removal of
glibc-headersdependencies will be appreciated.
- Release engineering: #9384 (a check of an impact with Release Engineering is needed)
- Policies and guidelines: The packaging guidelines already recommend a dependency on
gcc-c++for the appropriate compiler, so they do not need changing.
- Trademark approval: N/A (not needed for this Change)
The goal is more seamless in-place upgrades.
The removal of
glibc-headers dependencies is optional because there are compatibility
How To Test
Regular system upgrades of rawhide will implicitly test this change, and so will upgrades from previous Fedora versions.
There is no change in user experience.
This change can be implemented on its own.
- Contingency mechanism: Revert the change and bring back the
glibc-headerspackage as it exists today.
- Contingency deadline: before Beta
- Blocks release? no
- Blocks product? no
No documentation update is needed.
The removal of the
glibc-headers package should be mentioned, and that build-time dependencies should be on the compiler packages (or
glibc-devel, if that makes more sense for some reason.)