Bug 1230505

So what package should I require, if my code includes some standard C library headers (e.g. <string.h>)?

From you reports it looks like gcc will bundle glibc. Please note that relying on transitive dependency (gcc pulls in glibc-headers) is as wrong as relying already gone minimal build root package list.

And what if I need headers because I use cpp only to expand them. Which package should I require?

I think better approach would be first create stable standard library header RPM Provides symbol, then migrate the packages to require it, and then shuffle the header files wherever you want.

(In reply to Petr Pisar from comment #1)
> So what package should I require, if my code includes some standard C
> library headers (e.g. <string.h>)?

You should BuildRequires: gcc if you have C code you need to compile.

The glibc-headers is an implementation detail of the underlying tools infrastructure.

Using BuildRequires: gcc or BuildRequires: gcc-c++ gives you everything you need to compile standards conforming C or C++ applications.

> From you reports it looks like gcc will bundle glibc. Please note that
> relying on transitive dependency (gcc pulls in glibc-headers) is as wrong as
> relying already gone minimal build root package list.

You are not relying on any transitive dependency. The compiler, runtime, and headers form an "implementation" which is maintained by the Fedora platform tools team (RHEL BaseOS Platform Tools team). We guarantee that "BuildRequires: gcc" will give you exactly what you need to build conforming standard C applications.

The C library and it's headers are not a stand-alone thing like other packages, they are a special part of a coordinated implementation of a language.

> And what if I need headers because I use cpp only to expand them. Which
> package should I require?

Is there such a use case? Is there such a package? We can certainly discuss this use case if it exists.

The problem with such a use case is that glibc-headers is *incomplete* without the compiler headers provided by gcc which are also a required part of the runtime. Therefore if you have this use case today you must require gcc or gcc-c++ to get all of the headers you need.

> I think better approach would be first create stable standard library header
> RPM Provides symbol, then migrate the packages to require it, and then
> shuffle the header files wherever you want.

The bugs I have filed are for packages that don't even need glibc-headers, the BuildRequires has been copied from other spec files without consideration for what is needed. The majority of the 24 packages that require glibc-headers really need to BuildRequires on gcc or gcc-c++.

There is no immediate need for a stable standard library header RPM provides symbol, but I'm open to discussion if there is a package that needs such a requirement.

For reference to those asking "Why did the fedora packaging guidelines change?"

https://lists.fedoraproject.org/pipermail/devel/2015-May/210766.html

The BuildRequires section of the guidelines has been revised; the
exceptions list is gone.  The release engineering folks are free to
define the buildroot and rpm is free to change its dependency list.
 * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2
 * https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelines&diff=413629&oldid=409506
 * https://fedorahosted.org/fpc/ticket/497

Build Essentials discussion:
https://lists.fedoraproject.org/pipermail/devel/2015-June/211301.html

> We guarantee that "BuildRequires: gcc" will give you exactly what you need to
> build conforming standard C applications.

Than please add it into packaging guidelines or to the gcc package description.

> Is there such a use case? Is there such a package? We can certainly discuss
> this use case if it exists.

We have various devel packages that include other's headers files. Therefore they have to run-require their providers. What package should the devel package run-require in case of standard header files? As an example you can take libecb. Should the packages run-require gcc package?

(In reply to Petr Pisar from comment #5)
> > We guarantee that "BuildRequires: gcc" will give you exactly what you need to
> > build conforming standard C applications.
> 
> Than please add it into packaging guidelines or to the gcc package
> description.

Filed.

https://fedorahosted.org/fpc/ticket/540

> > Is there such a use case? Is there such a package? We can certainly discuss
> > this use case if it exists.
> 
> We have various devel packages that include other's headers files. Therefore
> they have to run-require their providers. What package should the devel
> package run-require in case of standard header files? As an example you can
> take libecb. Should the packages run-require gcc package?

In general if a devel package uses headers from another package it must have a "Requires: foo" on that package.

The exception is for standard C and C++ headers that are part of the "implementation" of the language. A devel package that uses standard's conforming headers need not run-require anything. The final user of the devel package will need a standards conforming compiler to compile the code, and that will bring in the required headers.

Hopefully the FPC request is approved and the text there clarifies what packagers should list in their BuildRequires or Requires.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

We now have a Application Specific Guideline for C and C++:
https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B

This should clarify how and when you need to require a C or C++ compilation environment.

Wa have a second version already under development to clarify questions raised from developers:
https://fedoraproject.org/wiki/C_and_C%2B%2B_v2

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

I don't think we still plan to remove the glibc-headers subpackage.

In any case, we'd need to push out the changes ourselves to the affected patches, perhaps after coordinating with Fesco.  Mere filing bugs will not get this done.