| |
@@ -219,7 +219,7 @@
|
| |
|
| |
If upstream's build scripts support the use of `+%{_libexecdir}+`
|
| |
then that is the most appropriate place to configure it
|
| |
- (eg. passing `+--libexecdir=%{_libexecdir}/%{name}+` to autotools configure).
|
| |
+ (e.g., passing `+--libexecdir=%{_libexecdir}/%{name}+` to autotools configure).
|
| |
If upstream's build scripts do not support that,
|
| |
`+%{_libdir}/%{name}+` is a valid second choice.
|
| |
If you have to patch support for using one of these directories in,
|
| |
@@ -441,7 +441,7 @@
|
| |
|
| |
== Conditional build-time dependencies
|
| |
|
| |
- If the spec file contains conditional dependencies selected based on presence of optional `+--with(out) foo+` arguments to `+rpmbuild+`, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the `+rpmbuild+` command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply.
|
| |
+ If the spec file contains conditional dependencies selected based on presence of optional `+--with(out) foo+` arguments to `+rpmbuild+`, build the source RPM to be submitted with the default options, i.e., so that none of these arguments are present in the `+rpmbuild+` command line. The reason is that those requirements get "serialized" into the resulting source RPM, i.e., the conditionals no longer apply.
|
| |
|
| |
== Summary and description
|
| |
|
| |
@@ -453,7 +453,7 @@
|
| |
|
| |
Packagers should be careful how they use trademarks in Summary or Description. There are a few rules to follow:
|
| |
|
| |
- * Never use "(TM)" or "(R)" (or the unicode equivalents, ™/®). It is incredibly complicated to use these properly, so it is actually safer for us to not use them at all.
|
| |
+ * Never use "(TM)" or "(R)" (or the Unicode equivalents, ™/®). It is incredibly complicated to use these properly, so it is actually safer for us to not use them at all.
|
| |
* Use trademarks in a way that is not ambiguous. Avoid phrasing like "similar to" or "like". Some examples:
|
| |
|
| |
* *BAD:* It is similar to Adobe Photoshop.
|
| |
@@ -711,7 +711,7 @@
|
| |
unversioned library symlink and the dynamic linker will link against the
|
| |
correct object.
|
| |
|
| |
- Keep in mind that although the filename is usually the library's SONAME plus an incrementing minor version there's nothing that intrinsically links these. ldconfig uses the SONAME as the value for a symlink to the actual filename. The dynamic linker then uses that symlink to find the library, disregarding the actual filename. The dynamic linker merely does a simple equality check on the field and does not check for ABI incompatibilities or similar problems. This is the main reason for using an {abi-comparison-tool} and incrementing the the SONAME.
|
| |
+ Keep in mind that although the filename is usually the library's SONAME plus an incrementing minor version there's nothing that intrinsically links these. ldconfig uses the SONAME as the value for a symlink to the actual filename. The dynamic linker then uses that symlink to find the library, disregarding the actual filename. The dynamic linker merely does a simple equality check on the field and does not check for ABI incompatibilities or similar problems. This is the main reason for using an {abi-comparison-tool} and incrementing the SONAME.
|
| |
|
| |
The SONAME field is written to the shared object by linker, using (at least in case of `+ld+`) the `+-soname SONAME+` flags. This can be passed as an option to `+gcc+` like this:
|
| |
|
| |
@@ -728,9 +728,9 @@
|
| |
[#packaging-static-libraries]
|
| |
== Packaging Static Libraries
|
| |
|
| |
- Packages including libraries SHOULD exclude static libs as far as possible (eg by configuring with _--disable-static_). Applications linking against libraries SHOULD link against shared libraries not static versions.
|
| |
+ Packages including libraries SHOULD exclude static libs as far as possible (e.g., by configuring with _--disable-static_). Applications linking against libraries SHOULD link against shared libraries not static versions.
|
| |
|
| |
- Libtool archives, _foo.la_ files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with _--disable-static_, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files SHOULD be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.
|
| |
+ Libtool archives, _foo.la_ files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with _--disable-static_, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files SHOULD be treated as an API/ABI change -- i.e., removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.
|
| |
|
| |
=== Packaging Static Libraries
|
| |
|
| |
@@ -995,8 +995,8 @@
|
| |
|
| |
Fedora's RPM includes a `+%makeinstall+` macro but it must *NOT* be used when make install DESTDIR=%\{buildroot} works. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:
|
| |
|
| |
- * `+%makeinstall+` overrides a set of Make variables during "make install" and prepends the %\{buildroot} path. I.e. it performs make prefix="%\{buildroot}%\{_prefix}" libdir="%\{buildroot}%\{_libdir} ...".
|
| |
- * It is error-prone and can have unexpected effects when run against less than perfect Makefiles, e.g. the buildroot path may be included in installed files where variables are substituted at install-time.
|
| |
+ * `+%makeinstall+` overrides a set of Make variables during "make install" and prepends the %\{buildroot} path, i.e. it performs make prefix="%\{buildroot}%\{_prefix}" libdir="%\{buildroot}%\{_libdir} ...".
|
| |
+ * It is error-prone and can have unexpected effects when run against less than perfect Makefiles, e.g., the buildroot path may be included in installed files where variables are substituted at install-time.
|
| |
* It can trigger unnecessary and wrong rebuilds when executing "make install", since the Make variables have different values compared with the %build section.
|
| |
* If a package contains libtool archives, it can cause broken *.la files to be installed.
|
| |
|
| |
@@ -1045,17 +1045,17 @@
|
| |
|
| |
Additionally, if your package cannot build without a specific scripting language (such as Ruby, or Tcl), and therefore already has a BuildRequires on that language, it may also be called from the spec file.
|
| |
|
| |
- Note: If you call perl or python in your spec file (and it is not already a BuildRequires for the package), you need to explicitly add a BuildRequires for perl or python.
|
| |
+ Note: If you call Perl or Python in your spec file (and it is not already a BuildRequires for the package), you need to explicitly add a BuildRequires for Perl or Python.
|
| |
|
| |
== %global preferred over %define
|
| |
|
| |
Use `+%global+` instead of `+%define+`, unless you really need only locally defined submacros within other macro definitions (a very rare case).
|
| |
|
| |
- Rationale: The two macro defining statements behave the same when they are a the top level of rpm's nesting level.
|
| |
+ Rationale: The two macro defining statements behave the same when they are at the top level of rpm's nesting level.
|
| |
|
| |
But when they are used in nested macro expansions (like in `+%{!?foo: ... }+` constructs, `+%define+` theoretically only lasts until the end brace (local scope), while `+%global+` definitions have global scope.
|
| |
|
| |
- Note that %define and %global differ in more ways than just scope: the body of a %define'd macro is lazily expanded (ie when used), but the body of %global is expanded at definition time. It's possible to use %%-escaping to force lazy expansion of %global.
|
| |
+ Note that %define and %global differ in more ways than just scope: the body of a %define'd macro is lazily expanded (i.e., when used), but the body of %global is expanded at definition time. It's possible to use %%-escaping to force lazy expansion of %global.
|
| |
|
| |
== Handling Locale Files
|
| |
|
| |
@@ -1192,9 +1192,9 @@
|
| |
|
| |
== Timestamps
|
| |
|
| |
- When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. `+cp -p+` or `+install -p+`.
|
| |
+ When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, e.g., `+cp -p+` or `+install -p+`.
|
| |
|
| |
- When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example `+wget -N+` or `+curl -R+`. To make the change global for wget, add this to your `+~/.wgetrc+`: `+timestamping = on+`, and for curl, add to your `+~/.curlrc+`: `+-R+`.
|
| |
+ When downloading sources, patches etc., consider using a client that preserves the upstream timestamps. For example `+wget -N+` or `+curl -R+`. To make the change global for wget, add this to your `+~/.wgetrc+`: `+timestamping = on+`, and for curl, add to your `+~/.curlrc+`: `+-R+`.
|
| |
|
| |
== Parallel make
|
| |
|
| |
@@ -1539,7 +1539,7 @@
|
| |
|
| |
Examples of packages that should explicitly provide only arch-specific `+Provides:+` include native code libraries or plug-ins and their associated -devel packages. Packages that should explicitly provide only arch-independent `+Provides:+` include most stand-alone programs (in addition to all noarch packages). Even though these programs may themselves be arch-specific, clients that run them should not care about their arch in most cases. A package that explicitly provides, for example, both a native code library as well as an interpreted language interface to that library should have both arch-specific (for clients of the native code library) and arch-independent (for clients of the interpreted language interface) Provides:.
|
| |
|
| |
- If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (ie. if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2)), and the distro version where it is planned to be dropped documented in a comment in the specfile. Maintainers of affected packages should be notified and encouraged to switch to use the new name. Forward compatibility Provides: in older distro branches can be considered in order to make it possible for package maintainers to keep same simple specfiles between branches but still switch to the newer name.
|
| |
+ If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (i.e., if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2)), and the distro version where it is planned to be dropped documented in a comment in the specfile. Maintainers of affected packages should be notified and encouraged to switch to use the new name. Forward compatibility Provides: in older distro branches can be considered in order to make it possible for package maintainers to keep same simple specfiles between branches but still switch to the newer name.
|
| |
|
| |
For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there.
|
| |
|
| |
@@ -1561,7 +1561,7 @@
|
| |
|
| |
== Build time network access
|
| |
|
| |
- Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don't themselves create (ie, for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository.
|
| |
+ Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don't themselves create (i.e., for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository.
|
| |
|
| |
[#bootstrapping]
|
| |
== Bootstrapping
|
| |
@@ -1592,7 +1592,7 @@
|
| |
when bootstrapping mode is enabled,
|
| |
the `+~bootstrap+` suffix is appended to the dist tag.
|
| |
This avoids the need to bump release
|
| |
- between bootsrap and final build.
|
| |
+ between bootstrap and final build.
|
| |
You can temporarily enable bootstrapping by commit,
|
| |
which changes `+%bcond_with bootstrap+` to `+%bcond_without bootstrap+`
|
| |
and later reverting the commit to do final build.
|
| |
Shouldn't it be ", e.g."?