(Created page with "== BuildRequires: pkgconfig(foo) vs. foo-devel == === Proposal === Fedora packages which use <code>pkg-config</code> to build against a library (e.g. 'foo') on which they dep...") |
(Incorporate feedback from https://fedorahosted.org/fpc/ticket/320#comment:1) |
||
| Line 2: | Line 2: | ||
=== Proposal === | === Proposal === | ||
Fedora packages which use <code>pkg-config</code> to build against a library (e.g. 'foo') on which they depend, ''' | Fedora packages which use <code>pkg-config</code> to build against a library (e.g. 'foo') on which they depend, '''MUST''' express their build dependency correctly as <code>pkgconfig(foo)</code>. | ||
Packages which do not use <code>pkg-config</code> '''MUST NOT''' use the <code>pkgconfig(foo)</code> form of the dependency. | |||
=== Rationale === | === Rationale === | ||
| Line 10: | Line 12: | ||
Thus, <code>pkgconfig(foo)</code> is the true statement of the build dependency, and is how it should be expressed in the spec file. | Thus, <code>pkgconfig(foo)</code> is the true statement of the build dependency, and is how it should be expressed in the spec file. | ||
For historical reasons, | For historical reasons, many packages seem to have a hard-coded "<code>BuildRequires: foo-devel</code>", with the name of the package which ''currently'' provides the required pkgconfig module. This is fragile and less portable than simply expressing the real dependency. Where package names change, and/or a required pkgconfig module is later provided by a ''different'' package, these hard-coded dependencies break. | ||
Note that it shall still be acceptable to require specific packages by name if they are required for some reason ''other'' than a <code>pkg-config</code> module that they provide. | |||
=== Example === | === Example === | ||
Revision as of 15:07, 25 July 2013
BuildRequires: pkgconfig(foo) vs. foo-devel
Proposal
Fedora packages which use pkg-config to build against a library (e.g. 'foo') on which they depend, MUST express their build dependency correctly as pkgconfig(foo).
Packages which do not use pkg-config MUST NOT use the pkgconfig(foo) form of the dependency.
Rationale
The build infrastructure for a given package will often locate and use required libraries by using pkg-config.
Thus, pkgconfig(foo) is the true statement of the build dependency, and is how it should be expressed in the spec file.
For historical reasons, many packages seem to have a hard-coded "BuildRequires: foo-devel", with the name of the package which currently provides the required pkgconfig module. This is fragile and less portable than simply expressing the real dependency. Where package names change, and/or a required pkgconfig module is later provided by a different package, these hard-coded dependencies break.
Note that it shall still be acceptable to require specific packages by name if they are required for some reason other than a pkg-config module that they provide.
Example
Packages which build against libproxy should contain the following:
BuildRequires: pkgconfig(libproxy-1.0)
... and not the following:
BuildRequires: libproxy-devel
This way, if the libproxy-1.0.pc pkgconfig module is ever provided from a differently-named package (such as by PacRunner once its integration is complete, or by a 'libproxy1' backward-compatibility package as has happened to a number of other libraries in the past), the dependency will continue to be correct.