C and C++ Packaging Guidelines
The C and C++ languages and runtimes are one of the most common development frameworks for packages in fedora. As such there is a wide variety of quality, style, and convention in all of those packages. The follow document provides best practice for certain aspects of C and C++ packaging.
If your application is a C or C++ application
you must list a
Those packages will include everything that is required
to build a standards conforming C or C++ application.
If your library includes standard C or C++ headers,
you must list
to install the needed standards conforming headers.
If at runtime you use
cpp to process C or C++ language headers
then you have no choice but to use
to install the required headers
for a standard conforming C or C++ application.
In the future this might change
if a set of standard C or C++ language headers are provided
by a special-purpose provides e.g.
You need not include a
or any other core C or C++ implementation package
unless you have a specific and special need
e.g. static compilation requires the
.*-static library packages
The default use case of a dynamically compiled C or C++ application
is taken care of by the
Please refer to Compiler Guidelines for the list of supported compilers for C and C++ compilers.
Do I need a
Requires: glibcto ensure I have the C runtime installed for my application?
No. RPM will automatically determine what ELF libraries you need based on the binaries in your package. This is sufficient to cause glibc to be installed.
Do I need to include a
If you are using an API from
libgccdirectly, then yes, you must have a
Requires: libgcc. In general though
libgcc, so it is always installed.
Libraries should have unique shared object names
that do not conflict with other library SONAMEs used in the distribution.
For example there should be only one
libfoo.so in the distribution.
The exception is when there are multiple implementations of the same library
libfoo.so provided by different authors and each conflicts with the other.
In this case both
libfoo.so must provide exactly the same interface,
but with a different implementation.
libfoo.so each with a different API is bad practice
and makes it harder to package and distribute those packages.
Libraries should version all of their symbols using a version script. Versioning allows the library to avoid changing the SONAME when the API changes and instead compatibility functions can be written to provide backwards compatibility for older applications.