Fedora 33 System-Wide Change proposal: Removal of the glibc-headers package

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RemoveGlibcHeaders

== Summary ==
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 my install it,
causing future upgrade problems.

== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:[e-mail] fweimer(a)redhat.com]

== Detailed Description ==

If `glibc-headers.i686` is installed for some reason and it vanishes
again from the compose, the system cannot be updated anymore using
`dnf update`.

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.

[https://pagure.io/releng/issue/8337 releng issue #8337] contains
further background information.

== Benefit to Fedora ==

System upgrades will work more reliably.

== Scope ==
* Proposal owners: Implement the glibc changes and remove some of the
build dependencies on `glibc-headers`.

* Other developers: Help with the removal of `glibc-headers`
dependencies will be appreciated.

* Release engineering: [https://pagure.io/releng/issue/9384 #9384] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)?  Is a mass rebuild required?  include a link to the releng
issue.
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->

* Policies and guidelines: The packaging guidelines already recommend
a dependency on `gcc` or `gcc-c++` for the appropriate compiler, so
they do not need changing.

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


== Upgrade/compatibility impact ==

The goal is more seamless in-place upgrades.

The removal of `glibc-headers` dependencies is optional because there
are compatibility `Provides:`.

== How To Test ==

Regular system upgrades of rawhide will implicitly test this change,
and so will upgrades from previous Fedora versions.

== User Experience ==

There is no change in user experience.

== Dependencies ==

This change can be implemented on its own.

== Contingency Plan ==

* Contingency mechanism: Revert the change and bring back the
`glibc-headers` package as it exists today.
* Contingency deadline: before Beta
* Blocks release? no
* Blocks product? no

== Documentation ==

No documentation update is needed.

== Release Notes ==

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.)


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Fri, Apr 3, 2020 at 1:20 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/RemoveGlibcHeaders
>
>  == Summary ==
>  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 my install it,
>  causing future upgrade problems.
>
>  == Owner ==
>  * Name: [[User:fweimer| Florian Weimer]]
>  * Email: [mailto:[e-mail] fweimer(a)redhat.com]
>
>  == Detailed Description ==
>
>  If `glibc-headers.i686` is installed for some reason and it vanishes
>  again from the compose, the system cannot be updated anymore using
>  `dnf update`.
>
>  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.
>
>  [https://pagure.io/releng/issue/8337 releng issue #8337] contains
>  further background information.
>  
Maybe this is a dumb question, but why do we not want to ship this? I
can't seem to figure out why we keep trying to block it, what harm it
causes to ship it, and so on...


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Florian Weimer]

* Neal Gompa:

>  Maybe this is a dumb question, but why do we not want to ship this?
> I
>  can't seem to figure out why we keep trying to block it, what harm it
>  causes to ship it, and so on... 
We haven't been able to ship it *consistently*.  It either has to be
always available in the x86_64 compose, or never.  It can't change from
day to day, that does not work.

My understanding is that it's currently not possible to exclude packages
based on name and architecture, so changing the glibc package seems the
easy way out.

Thanks,
Florian

[Jakub Jelinek]

On Fri, Apr 03, 2020 at 07:36:34PM +0200, Florian Weimer wrote:
>  * Neal Gompa:
>  
>  > Maybe this is a dumb question, but why do we not want to ship this? I
>  > can't seem to figure out why we keep trying to block it, what harm it
>  > causes to ship it, and so on...
>  
>  We haven't been able to ship it *consistently*.  It either has to be
>  always available in the x86_64 compose, or never.  It can't change from
>  day to day, that does not work.
>  
>  My understanding is that it's currently not possible to exclude packages
>  based on name and architecture, so changing the glibc package seems the
>  easy way out. 
We should way to do that, perhaps not by name and architecture, but name and
whether the multilib is non-primary.
There are other packages like gcc-* subpackages that really have to come
only from the primary multilib arch and not the secondary ones and from time
to time bogus dependencies in other packages bring it in.
glibc-headers is the same category.

	Jakub