|
|
(287 intermediate revisions by 11 users not shown) |
Line 1: |
Line 1: |
| <!-- page was renamed from PackagingGuidelines
| | {{DISPLAYTITLE:Fedora Packaging Guidelines}} |
| -->
| |
| = Packaging Guidelines =
| |
|
| |
|
| It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee.
| | {{admon/warning |The packaging guidelines have been moved out of the wiki. The current version of this document is located at https://docs.fedoraproject.org/en-US/packaging-guidelines/ . Please update your bookmarks.}} |
| | |
| Please remember that any package that you submit must also conform to the [[Packaging:ReviewGuidelines| Review Guidelines]] .
| |
| | |
| '''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)<BR>
| |
| '''Revision:''' 1.00<BR>
| |
| '''Initial Draft:''' Wednesday Feb 23, 2005<BR>
| |
| '''Last Revised:''' Tuesday July 21, 2009<BR>
| |
| | |
| {{Anchor|Naming}}
| |
| == Naming ==
| |
| | |
| You should go through the [[Packaging:NamingGuidelines]] to ensure that your package is named appropriately.
| |
| | |
| == Version and Release ==
| |
| | |
| Documentation covering the proper way to use the Version and Release fields can be found here: [[Packaging:NamingGuidelines#Package_Version]]
| |
| | |
| {{Anchor|Legal}}
| |
| == Legal ==
| |
| | |
| There are various legal concerns to consider when packaging for Fedora.
| |
| | |
| {{Anchor|LegalLicensing}}
| |
| === Licensing ===
| |
| | |
| You should review [[Licensing:Main]] and the [[Packaging:LicensingGuidelines]] to ensure that your package is licensed appropriately.
| |
| | |
| | |
| {{Anchor|External Bits}}
| |
| === Packages which are not useful without external bits ===
| |
| | |
| Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency).
| |
| | |
| This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora.
| |
| | |
| {{Anchor|SourceRequirement}}
| |
| | |
| == No inclusion of pre-built binaries or libraries ==
| |
| | |
| All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. This is a requirement for the following reasons:
| |
| * Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch.
| |
| * Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.
| |
| | |
| Content binaries (such as .mo, .pdf, .png, .ps files) are ''not'' required to be rebuilt from the source code.
| |
| | |
| If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria:
| |
| * Is it executable? If so, it is probably a program binary.
| |
| * Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a program library.
| |
| * If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee.
| |
| | |
| Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).
| |
| | |
| When you encounter prebuilt binaries in a package you '''MUST''':
| |
| | |
| * Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so files.
| |
| * Ask upstream to remove the binaries in their next release.
| |
| | |
| {{Anchor|SourceRequirementExceptions}}
| |
| === Exceptions ===
| |
| | |
| * Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval.
| |
| * An exception is made for binary firmware, as long as it meets the requirements documented here: [[Licensing:Main#Binary_Firmware]]
| |
| * Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: [[Packaging:SourceURL#When_Upstream_uses_Prohibited_Code]]
| |
| | |
| {{Anchor|Spec Legibility}}
| |
| | |
| == Spec Legibility ==
| |
| All Fedora Package Spec Files must be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Spec files are not the place for entries into the [http://www.ioccc.org/ Obfuscated Code Contest].
| |
| | |
| {{Anchor|PackageFromScratch}}
| |
| == Writing a package from scratch ==
| |
| When writing a package from scratch, you should base your spec file on the Fedora spec file template (see [[Rpmdevtools]] ). Please put your preferences about spec file formatting and organization aside, and try to conform to this template as much as possible. This is not because we believe this is the only right way to write a spec file, but because it often makes it easier for QA to spot mistakes and quickly understand what you are trying to do.
| |
| | |
| {{Anchor|ModifyingExistingPackage}}
| |
| == Modifying an existing package ==
| |
| If you base a package on an existing non-Fedora package, be careful to verify its correctness and to understand exactly what goes on. Do not submit a package without knowing what those strange, but innocent-looking commands do.
| |
| | |
| In particular, you should
| |
| *verify any sources and patches.
| |
| *verify that the license stated in the spec file matches the actual license of the software (see [[#tags| Tags]] ),
| |
| *skim the summary and description for typos and oddities (see [[#summary| Summary and description]] ),
| |
| *make sure that the correct build root is used,
| |
| *ensure that macro usage is consistent (see [[#macros| Macros]] ).
| |
| | |
| Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.
| |
| | |
| {{Anchor|ArchitectureSupport}}
| |
| == Architecture Support ==
| |
| All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture. Fedora packagers should make every effort to support all [[Architectures#Primary_Architectures|primary architectures]].
| |
| | |
| Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions.
| |
| | |
| === Architecture Build Failures ===
| |
| If a Fedora package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in <code>ExcludeArch</code>. Each architecture listed in <code>ExcludeArch</code> needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding <code>ExcludeArch</code> line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues:
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-arm F-ExcludeArch-arm]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-s390x F-ExcludeArch-s390x]
| |
| * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-sparc F-ExcludeArch-sparc]
| |
| | |
| {{Anchor|layout}}
| |
| | |
| == Filesystem Layout ==
| |
| | |
| Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages must follow the FHS. Any deviation from the FHS should be rationalized when the package is reviewed.
| |
| | |
| There are notable exceptions to this guideline for libexecdir (as specified in the [http://www.gnu.org/prep/standards/standards.html#index-libexecdir-139 GNU Coding Standards]) and /usr/target for cross-compilers.
| |
| | |
| {{Anchor|libexecdir}}
| |
| === Libexecdir ===
| |
| | |
| The [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] does not include any provision for libexecdir, but Fedora packages can store appropriate files there. Libexecdir (aka, /usr/libexec on Fedora systems) should be used as the directory for executable programs that are designed primarily to be run by other programs rather than by users.
| |
| Fedora's rpm includes a macro for libexecdir, <code>%{_libexecdir}</code>. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of <code>%{_libexecdir}</code>, such as <code>%{_libexecdir}/%{name}</code>.
| |
| | |
| {{Anchor|rpmlint}}
| |
| | |
| == Use rpmlint ==
| |
| Run rpmlint on binary and source rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the <code>-i</code> switch to it can be used to get more verbose descriptions of most errors and warnings. Note that rpmlint will perform additional checks if given the name of an installed package. For example, <code>yum install foo-1.0-1.f20.x86_64.rpm; rpmlint foo</code> will perform a set of tests on the foo package that <code>rpmlint foo-1.0-1.f20.x86_64.rpm</code> cannot. The rpmlint package is available in the Fedora repositories.
| |
| | |
| === Rpmlint Errors ===
| |
| | |
| Rpmlint has the ability to make a lot of noise when it is run, even on perfectly valid packages. This section exists to help you decipher the messages, so that you can make fixes as necessary.
| |
| | |
| * <code>E: foo-package no-packager-tag</code>: This error occurs because no <code>Packager:</code> value is defined in the spec file. In Fedora, we do not use the <code>Packager</code> tag, so you can ignore this error.
| |
| * <code>E: foo-package no-signature</code>: This error occurs because your package is not signed. Since Fedora doesn't store SRPMS in CVS (only the files inside them), you do not need to sign your package, and you can ignore this error.
| |
| * <code>W: foo-package summary-ended-with-dot Summary of my package.</code>: This error occurs because the entry in your spec for <code>Summary:</code> ended with a period. Just get rid of the period at the end of the line.
| |
| * <code>E: foo-package wrong-script-end-of-line-encoding /path/to/somefile</code>: This error occurs because of DOS line breaks in a file. Fix it in the %prep section with sed: <code>%{__sed} -i 's/\r//' src/somefile</code> or <code>dos2unix</code>.
| |
| | |
| * <code>E: foo-package invalid-lc-messages-dir /usr/share/locale/xx_XX/LC_MESSAGES/foo.mo</code>: This error is a common false positive and usually should be ignored.
| |
| | |
| {{Anchor|Changelogs}}
| |
| | |
| == Changelogs ==
| |
| ''Every time'' you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packages, and QA people to easily spot the changes that you make.
| |
| | |
| If a particular change is related to a Bugzilla bug, include the bug ID in the changelog entry for easy reference, e.g.
| |
| | |
| <pre>
| |
| * Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2
| |
| - Added README file (#42).
| |
| </pre>
| |
| | |
| You must use one of the following formats:
| |
| <pre>
| |
| * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
| |
| - And fix the link syntax.
| |
| </pre>
| |
| | |
| <pre>
| |
| * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
| |
| - And fix the link syntax.
| |
| </pre>
| |
| | |
| <pre>
| |
| * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
| |
| - 0.6-4
| |
| - And fix the link syntax.
| |
| </pre>
| |
| | |
| Changelog entries should provide a brief summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They must never simply contain an entire copy of the source CHANGELOG entries. The intent is to give the user a hint as to what changed in a package update without overwhelming them with the technical details. Links to upstream changelogs can be entered for those who want additional information.
| |
| | |
| === Multiple Changelog Entries per Release ===
| |
| In some situations, it may be useful for packagers to have multiple changelog entries in the spec file, but not increment the release field for each one. There are two supported methods for doing this:
| |
| | |
| ==== Updating and replacing the existing date line ====
| |
| | |
| In this situation, you have added this changelog entry, but have not built the package yet:
| |
| | |
| <pre>
| |
| * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
| |
| - Fix spelling errors in package description
| |
| </pre>
| |
| | |
| The next day, you make additional changes to the spec, and need to add a new changelog line, then you would update the existing date line for 1.0-1, and append any new notes, making the changelog look like this:
| |
| | |
| <pre>
| |
| * Nov 13 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
| |
| - Fix spelling errors in package description
| |
| - Add a patch to fix compilation problems on F15
| |
| </pre>
| |
| | |
| Please remember that this is only acceptable if 1.0-1 has not yet been built.
| |
| | |
| You can do this any number of times, until you actually build 1.0-1 in the buildsystem. At that point, you must go back to adding new entries as described in [[Packaging:Guidelines#Changelogs|Changelogs]].
| |
| | |
| | |
| ==== Repeat the old version release with a new entry ====
| |
| | |
| In this situation, you have added this changelog entry, but have not built the package yet:
| |
| | |
| <pre>
| |
| * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
| |
| - Fix spelling errors in package description
| |
| </pre>
| |
| | |
| The next day, you make additional changes to the spec, and need to add a new changelog line. Now, you can add an additional changelog item with the new date, but the same Version-Release, so your new changelog looks like this:
| |
| | |
| <pre>
| |
| * Nov 13 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
| |
| - Add a patch to fix compilation problems on F15
| |
| | |
| * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
| |
| - Fix spelling errors in package description
| |
| </pre>
| |
| | |
| Please remember that this is only acceptable if 1.0-1 has not yet been built.
| |
| | |
| You can do this any number of times, until you actually build 1.0-1 in the buildsystem. At that point, you must go back to adding new entries as described in [[Packaging:Guidelines#Changelogs|Changelogs]].
| |
| | |
| {{Anchor|tags}}
| |
| | |
| == Tags ==
| |
| *The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
| |
| *The ''Vendor'' tag should not be used. It is set automatically by the build system.
| |
| *The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in [[Packaging:LicensingGuidelines]] . Contact the upstream author if there is any doubt about what license the software is distributed under.
| |
| *The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.
| |
| *Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
| |
| * The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball. For special cases, please see the [[Packaging:SourceURL]] Guidelines
| |
| | |
| {{Anchor|BuildRoot}}
| |
| | |
| == BuildRoot tag ==
| |
| | |
| Fedora (as of F-10) does not require the presence of the BuildRoot tag in the spec and if one is defined it will be ignored. The provided buildroot will automatically be cleaned before commands in %install are called.
| |
| | |
| {{admon/note|EPEL difference|rpm in EPEL5 and below require the BuildRoot tag and it must be manually cleaned in %install; follow the [[EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines|EPEL Guidelines]].}} | |
| | |
| {{Anchor|Clean}}
| |
| | |
| == %clean ==
| |
| The %clean section is not required for F-13 and above. Each package for F-12 and below (or EPEL) MUST have a %clean section, which contains <code>rm -rf %{buildroot}</code> ([[Packaging:Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).<BR> | |
| | |
| {{Anchor|Requires}}
| |
| | |
| == Requires ==
| |
| RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package.
| |
| | |
| Build requirements are different. There's no automatic dependency find procedure for them, which means that you must explicitly list stuff that the package requires to build successfully. Typically, some -devel packages are listed there. Refer to the [[#BuildRequires| BuildRequires section]] .
| |
| | |
| Sometimes we know that a package requires eg. gtk+-devel 1.2 or newer to build (and thus gtk+ 1.2 or newer to run, but that's handled automatically). There are two things to consider here:
| |
| | |
| First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, there's no need to include the version in the dependency at all. In that case we know the available software is new enough. For example, the version in gtk+-devel 1.2 dependency above is unnecessary for all Red Hat Linux distributions since (at least) release 6.2. As a rule of thumb, if the version is not required, don't add it just for fun.
| |
| | |
| Second, the Epoch must be listed when adding a versioned dependency to achieve robust epoch-version-release comparison. A quick way to check the Epoch of package foo is to run:
| |
| | |
| rpm --query --qf "%{EPOCH}\n" packagename
| |
| | |
| Typically, the requirements for -devel packages need yet another look. They're not usually picked up automatically by rpm. If the foo-devel package has a foo-config script, you can try doing a foo-config --libs and foo-config --cflags to get strong hints what packages should be marked as foo's requirements. For example:
| |
| | |
| <pre>
| |
| $ gtk-config --cflags
| |
| -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
| |
| $ gtk-config --libs
| |
| -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
| |
| </pre>
| |
| | |
| This means that gtk+-devel should contain
| |
| | |
| Requires: glib-devel libXi-devel libXext-devel libX11-devel
| |
| | |
| {{Anchor|PreReq}}
| |
| === PreReq ===
| |
| | |
| Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.
| |
| | |
| {{Anchor|FileDeps}}
| |
| === File Dependencies ===
| |
| | |
| Rpm gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice.
| |
| | |
| {{Anchor|ExplicitRequires}}
| |
| === Explicit Requires ===
| |
| Explicit Requires are Requires added manually by the packager in the spec file. Packages must not contain explicit ''Requires'' on libraries except when absolutely
| |
| necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.
| |
| | |
| We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
| |
| Modern package management tools are capable of resolving such dependencies to determine
| |
| the required packages. Explicit dependencies on specific package names may aid the
| |
| inexperienced user, who attempts at installing RPM packages manually, however, history
| |
| has shown that such dependencies add confusion when library/files are moved from one
| |
| package to another, when packages get renamed, when one out of multiple alternative
| |
| packages would suffice, and when versioned explicit dependencies become out-of-date and
| |
| inaccurate. Additionally, in some cases, old explicit dependencies on package names
| |
| require unnecessary updates/rebuilds. For example, Fedora packages are only required
| |
| to retain historical provides for two full release cycles.
| |
| | |
| Exemplary rationale for a versioned explicit dependency:
| |
| <pre>
| |
| # The automatic dependency on libfubar.so.1 is insufficient,
| |
| # as we strictly need at least the release that fixes two segfaults.
| |
| Requires: libfubar >= 0:1.2.3-7
| |
| </pre>
| |
| | |
| Packagers should revisit an explicit dependency as appropriate to avoid
| |
| it becoming inaccurate and superfluous. For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.
| |
| | |
| === Filtering Auto-Generated Requires ===
| |
| RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: [[Packaging:AutoProvidesAndRequiresFiltering]]
| |
| | |
| {{Anchor|BuildRequires}}
| |
| | |
| == BuildRequires ==
| |
| | |
| In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.
| |
| | |
| Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .
| |
| | |
| There are two suggested ways of detecting missing Build<code></code>Requires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[#rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more. <BR>
| |
| '''mock''' is another good way to check build dependencies. Rather than remove all developer packages, it tries to build your package in a chroot. It makes no changes to your normal, daily environment and ensures that your package will build fine. However, '''mock''' may need a good internet connection to download all required packages. [[Extras/MockTricks| MockTricks]] page contains more information. Another mock-like tool, '''mach''' is also available in the Fedora repository.
| |
| | |
| {{Anchor|rmdevelrpms}}
| |
| === rpmdev-rmdevelrpms ===
| |
| | |
| '''rpmdev-rmdevelrpms''' script within the [[rpmdevtools]] toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing Build<code></code>Requires. Simply run it and allow it to remove all *-devel packages and build tools like this example.
| |
| | |
| <pre>
| |
| [root@build-fc1 /] # rpmdev-rmdevelrpms
| |
| Found 52 devel packages:
| |
| guile-devel-1.6.4-8.2
| |
| bison-1.875-5
| |
| m4-1.4.1-14
| |
| flex-2.5.4a-30
| |
| openssl-devel-0.9.7a-23
| |
| automake-1.7.8-1
| |
| fontconfig-devel-2.2.1-6.1
| |
| XFree86-devel-4.3.0-42
| |
| tcl-devel-8.3.5-93
| |
| SDL_image-devel-1.2.3-3
| |
| SDL_ttf-devel-2.0.6-0.fdr.3.1
| |
| pth-devel-2.0.0-0.fdr.1.1
| |
| libIDL-devel-0.8.2-1
| |
| atk-devel-1.4.0-1
| |
| gtk2-devel-2.2.4-5.1
| |
| libmng-devel-1.0.4-4
| |
| glib-devel-1.2.10-11
| |
| gtk+-devel-1.2.10-28.1
| |
| audiofile-devel-0.2.3-7
| |
| compface-1.4-0.fdr.3.1
| |
| esound-devel-0.2.31-1
| |
| libungif-devel-4.1.0-16
| |
| gnome-libs-devel-1.4.1.2.90-35
| |
| openldap-devel-2.1.22-8
| |
| aspell-devel-0.50.3-16
| |
| gpgme03-devel-0.3.16-0.fdr.2.1
| |
| freeglut-devel-1.3-1.20020125.3
| |
| e2fsprogs-devel-1.34-1
| |
| db4-devel-4.1.25-14
| |
| krb5-devel-1.3.1-6
| |
| autoconf-2.57-3
| |
| libtool-1.5-8
| |
| gdbm-devel-1.8.0-21
| |
| freetype-devel-2.1.4-5
| |
| pkgconfig-0.14.0-6
| |
| ncurses-devel-5.3-9
| |
| tk-devel-8.3.5-93
| |
| SDL-devel-1.2.5-9
| |
| SDL_mixer-devel-1.2.4-9
| |
| zlib-devel-1.2.0.7-2
| |
| libgpg-error-devel-0.6-0.fr.3.1
| |
| glib2-devel-2.2.3-1.1
| |
| pango-devel-1.2.5-1.1
| |
| libjpeg-devel-6b-29
| |
| libpng-devel-1.2.2-17
| |
| ORBit-devel-0.5.17-10.3
| |
| clamav-devel-0.65-0.fdr.4.1
| |
| cyrus-sasl-devel-2.1.15-6
| |
| libtiff-devel-3.5.7-14
| |
| imlib-devel-1.9.13-14
| |
| gdk-pixbuf-devel-0.22.0-3.0
| |
| pilot-link-devel-0.11.8-1
| |
| Remove them? [y/N] y[
| |
| ]Removing.................................................................................................
| |
| ................................................................Done.
| |
| </pre>
| |
| Then attempt to build your RPM package. Use yum to reinstall any packages that are already in Build<code></code>Requires. If your build fails after this point, then you need to read through the build process and ascertain the missing Build<code></code>Requires from the error messages within.
| |
| | |
| Be very careful to watch especially the '''configure''' part of the build process for missing optional libraries or tools that are desirable for the package.
| |
| | |
| By default, the script may attempt to remove some packages that your system needs to operate correctly. Usually, this will fail due to an unsatisfied dependency (and this, BTW is why the script is using rpm -e instead of yum remove...)
| |
| | |
| An example of this are the gettext and libgcj packages. gettext is usually a development-only package, but for example redhat-lsb depends on it. Also, it seems that RH9 Konqueror needs openssl-devel for SSL. If you wish to mark some packages so that they will be ignored by rpmdev-rmdevelrpms, do it in /etc/rpmdevtools/rmdevelrpms.conf or your personal /.rmdevelrpmsrc and pay special attention to the packages you treated this way when building.
| |
| | |
| {{Anchor|Exceptions}}
| |
| === Exceptions ===
| |
| | |
| There is no need to include the following packages or their dependencies as Build<code></code>Requires because they would occur too often. These packages are considered the minimum build environment.
| |
| | |
| <pre>
| |
| bash
| |
| bzip2
| |
| coreutils
| |
| cpio
| |
| diffutils
| |
| fedora-release
| |
| findutils
| |
| gawk
| |
| gcc
| |
| gcc-c++
| |
| grep
| |
| gzip
| |
| info
| |
| make
| |
| patch
| |
| redhat-rpm-config
| |
| rpm-build
| |
| sed
| |
| shadow-utils
| |
| tar
| |
| unzip
| |
| util-linux-ng
| |
| which
| |
| </pre>
| |
| | |
| {{Anchor|summary}}
| |
| | |
| == Summary and description ==
| |
| The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.
| |
| | |
| Please put personal preferences aside and use American English spelling in the summary and description. Packages can contain additional translated summary/description for supported Non-English languages, if available.
| |
| | |
| === Trademarks in Summary or Description ===
| |
| 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.
| |
| * 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.
| |
| * '''GOOD:''' It supports Adobe Photoshop PSD files, ...
| |
| | |
| * '''BAD:''' A Linux version of Microsoft Office
| |
| * '''GOOD:''' A word-processor with support for Microsoft Office DOC files
| |
| | |
| If you're not sure, ask yourself, is there any chance someone may get confused and think that this package is the trademarked item? When in doubt, try to leave the trademark out.
| |
| | |
| {{Anchor|PackageEncoding}}
| |
| | |
| == Encoding ==
| |
| Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire] , you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart] .
| |
| | |
| {{Anchor|FilenameEncoding}}
| |
| === Non-ASCII Filenames ===
| |
| Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
| |
| | |
| {{Anchor|PackageDocumentation}}
| |
| == Documentation ==
| |
| Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.
| |
| | |
| Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.
| |
| | |
| In addition, <code>%doc</code> files must not have executable permissions.
| |
| | |
| {{Anchor|CompilerFlags}}
| |
| | |
| == Compiler flags ==
| |
| Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases.
| |
| | |
| {{Anchor|Debuginfo}}
| |
| == Debuginfo packages ==
| |
| Packages should produce useful <code>-debuginfo</code> packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a <code>-debuginfo</code> package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, [[Packaging:Debuginfo]] .
| |
| | |
| {{Anchor|DevelPackages}}
| |
| == Devel Packages ==
| |
| If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
| |
| * Header files (e.g. .h files)
| |
| * Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries (e.g. libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.
| |
| | |
| A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.
| |
| | |
| {{Anchor|PkgconfigFiles}}
| |
| === Pkgconfig Files ===
| |
| The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
| |
| A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb.
| |
| | |
| {{admon/note|EPEL difference|rpm in Fedora automatically detects dependencies on pkgconfig and between pkgconfig files. rpm in EPEL5 and below do not have this ability and should follow the [[EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines|EPEL Guidelines]].}}
| |
| | |
| {{Anchor|RequiringBasePackage}}
| |
| | |
| == Requiring Base Package ==
| |
| Subpackages are often extensions for their base package and in that case they should require their base package. It is almost always better to over specify the version, so it's best practice to just use a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Devel packages are an example of a package that must require their base packages using a fully versioned dependency. -libs subpackages which only contain shared libraries do not normally need to explicitly depend on %{name} = %{version}-%{release}, as they usually do not need the base package to be functional libraries.
| |
| | |
| If you end up in a situation where the main package depends on the subpackage and the subpackage on the main package you should think carefully about why you don't have everything in the main package.
| |
| | |
| {{Anchor|SharedLibraries}}
| |
| | |
| == Shared Libraries ==
| |
| Whenever possible (and feasible), Fedora Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
| |
| <pre>
| |
| %post -p /sbin/ldconfig
| |
| | |
| %postun -p /sbin/ldconfig
| |
| </pre>
| |
| Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
| |
| <pre>
| |
| %post
| |
| /sbin/ldconfig
| |
| /usr/bin/foo --add
| |
| | |
| %postun
| |
| /sbin/ldconfig
| |
| /usr/bin/foo --remove
| |
| </pre>
| |
| | |
| {{Anchor|StaticLibraries}}
| |
| == Packaging Static Libraries ==
| |
| Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible 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 and should not be undertaken lightly.
| |
| | |
| {{Anchor|StaticInclusion}}
| |
| === Packaging Static Libraries ===
| |
| * In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.
| |
| | |
| * We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
| |
| # '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
| |
| # '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
| |
| <pre>%package devel
| |
| Provides: foo-static = %{version}-%{release}</pre>
| |
| | |
| Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.
| |
| | |
| * If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.
| |
| | |
| {{Anchor|StaticLinkage}}
| |
| === Staticly Linking Executables ===
| |
| * Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval.
| |
| * If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are [[PackageMaintainers/CVSAdminProcedure| instructions]] for making that request.
| |
| | |
| ==== Programs which don't need to notify FESCo ====
| |
| * Programs written in OCaml do not normally link dynamically to OCaml libraries. Because of that this requirement is waived. (OCaml code that calls out to libraries written in C should still link dynamically to the C libraries, however.)
| |
| | |
| * If a library you depend on '''only''' provides a static version your package can link against it provided that you <code>BuildRequire</code> the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
| |
| | |
| ==== Programs which have been granted exceptions ====
| |
| * yaboot has permission to link statically since it's a boot loader that uses e2fsprogs-libs to read the filesystem
| |
| | |
| {{Anchor|SystemLibraryDuplication}}
| |
| | |
| == Duplication of system libraries ==
| |
| | |
| A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed.
| |
| | |
| In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future.
| |
| | |
| Some packages may be granted an exception to this. Please see the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page for rationale, the process for being granted an exception, and the requirements if your package is bundling.
| |
| | |
| For information on how to remove bundled libraries, see: [[Packaging:Treatment Of Bundled Libraries|Treatment Of Bundled Libraries]].
| |
| | |
| {{Anchor|Rpath}}
| |
| | |
| == Beware of Rpath ==
| |
| Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.
| |
| | |
| There is a tool called ''check-rpaths'' which is included in the ''rpmdevtools'' package. It is a good idea to add it to the ''<code>%__arch_install_post</code>'' macro in your ''<code>~/.rpmmacros</code>'' config file:
| |
| <pre>
| |
| %__arch_install_post \
| |
| /usr/lib/rpm/check-rpaths \
| |
| /usr/lib/rpm/check-buildroot
| |
| </pre>
| |
| | |
| When ''check-rpaths'' is run, you might see output like this:
| |
| <pre>
| |
| ERROR 0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64]
| |
| </pre>
| |
| | |
| Any rpath flagged by check-rpaths '''MUST''' be removed.
| |
| | |
| {{Anchor|AcceptableRpath}}
| |
| === Rpath for Internal Libraries ===
| |
| | |
| When a program installs internal libraries they are often not installed in the system path. These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables). These libraries are not intended for use outside of the package. When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries.
| |
| | |
| Example:
| |
| <pre>
| |
| # Internal libraries for myapp are present in:
| |
| %{_libdir}/myapp/
| |
| %{_libdir}/myapp/libmyapp.so.0.3.4
| |
| %{_libdir}/myapp/libmyapp.so
| |
| | |
| # myapp has an rpath to %{_libdir}/myapp/
| |
| readelf -d /usr/bin/myapp | grep RPATH
| |
| 0x0000000f (RPATH) Library rpath: [/usr/lib/myapp]
| |
| </pre>
| |
| | |
| {{admon/tip|Non-Internal Libraries|When programs outside of the package are supposed to link against the library, it is better to use the [[#AlternativeRpath| Alternative to Rpath]] or simply move the libraries into %{_libdir} instead. That way the dynamic linker can find the libraries without having to link all the programs with an rpath.}}
| |
| | |
| {{Anchor|AlternativeRpath}}
| |
| === Alternatives to Rpath ===
| |
| Often, rpath is used because a binary is looking for libraries in a non-standard location (standard locations are /lib, /usr/lib, /lib64, /usr/lib64). If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf" in /etc/ld.so.conf.d/, which contained the following:
| |
| <pre>
| |
| /usr/lib/foo
| |
| </pre>
| |
| Make sure that you also make a 64bit version of this file (e.g. foo64.conf) as well (unless the package is disabled for 64bit architectures, of course).
| |
| | |
| {{Anchor|RemovingRpath}}
| |
| === Removing Rpath ===
| |
| | |
| There are several different ways to fix the rpath issue:
| |
| | |
| * If the application uses configure, try passing the ''--disable-rpath'' flag to configure.
| |
| * If the application uses a local copy of libtool, add the following lines to the spec after %configure:
| |
| <pre>
| |
| %configure
| |
| sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
| |
| sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
| |
| </pre>
| |
| * Sometimes, the code/Makefiles can be patched to remove the ''-rpath'' or ''-R'' flag from being called. This is not always easy or sane to do, however.
| |
| * As a last resort, Fedora has a package called ''chrpath''. When this package is installed, you can run <code>chrpath --delete</code> on the files which contain rpaths. So, in our earlier example, we'd run:
| |
| <pre>
| |
| chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
| |
| </pre>
| |
| Make sure that you remember to add a '''BuildRequires: chrpath''' if you end up using this method.
| |
| | |
| {{Anchor|Config}}
| |
| == Configuration files ==
| |
| | |
| Configuration files must be marked as such in packages.
| |
| | |
| As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.
| |
| | |
| Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora.
| |
| | |
| {{Anchor|Init}}
| |
| {{Anchor|Initscripts}}
| |
| == Initscripts ==
| |
| | |
| Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: [[Packaging:SysVInitScript]]
| |
| | |
| {{Anchor|desktop}}
| |
| == Desktop files ==
| |
| | |
| If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
| |
| [http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
| |
| entries.
| |
| | |
| === Icon tag in Desktop Files ===
| |
| The icon tag can be specified in two ways:
| |
| | |
| * Full path to specific icon file:
| |
| <code> Icon=/usr/share/pixmaps/comical.png </code>
| |
| | |
| * Short name without file extension:
| |
| <code> Icon=comical </code>
| |
| | |
| The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.
| |
| | |
| === .desktop file creation ===
| |
| If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (e.g. Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):
| |
| | |
| <pre>
| |
| [Desktop Entry]
| |
| Name=Comical
| |
| GenericName=Comic Archive Reader
| |
| Comment=Open .cbr & .cbz files
| |
| Exec=comical
| |
| Icon=comical
| |
| Terminal=false
| |
| Type=Application
| |
| Categories=Graphics;
| |
| </pre>
| |
| | |
| === desktop-file-install usage ===
| |
| It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
| |
| usage:
| |
| | |
| <pre>
| |
| desktop-file-install \
| |
| --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
| |
| %{SOURCE3}
| |
| </pre>
| |
| | |
| <pre>
| |
| desktop-file-install \
| |
| --add-category="AudioVideo" \
| |
| --delete-original \
| |
| --dir=%{buildroot}%{_datadir}/applications \
| |
| %{buildroot}/%{_datadir}/foo.desktop
| |
| </pre>
| |
| | |
| <pre>
| |
| desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
| |
| </pre>
| |
| | |
| * For new packages, do not apply a vendor tag to desktop files. Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).
| |
| | |
| {{Anchor|macros}}
| |
| | |
| == Macros ==
| |
| Use macros instead of hard-coded directory names (see [[Packaging:RPMMacros]] ).
| |
| | |
| Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.
| |
| | |
| If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual Source: value, you can run:
| |
| <pre>
| |
| rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
| |
| </pre>
| |
| | |
| {{Anchor|UsingBuildRootOptFlags}}
| |
| === Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
| |
| There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:
| |
| | |
| {| border="1"
| |
| |-
| |
| | ||macro style || variable style
| |
| |-
| |
| |Build Root||%{buildroot}||$RPM_BUILD_ROOT
| |
| |-
| |
| |Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
| |
| |}
| |
| | |
| There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.
| |
| | |
| Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in Fedora packages.
| |
| | |
| {{Anchor|MakeInstall}}
| |
| === Why the %makeinstall macro should not be used ===
| |
| Fedora's RPM includes a <code>%makeinstall</code> 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:
| |
| * <code>%makeinstall</code> 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.
| |
| | |
| Instead, Fedora packages should use: <code>make DESTDIR=%{buildroot} install</code> or <code>make DESTDIR=$RPM_BUILD_ROOT install</code>
| |
| | |
| === Source RPM Buildtime Macros ===
| |
| All macros in <code>Summary:</code> and <code>%description</code> need to be expandable at srpm buildtime. Because SRPMs are built without the package's BuildRequires installed, depending on macros defined outside of the spec file can easily lead to the unexpanded macros showing up in the built SRPM. One way to check is to create a minimal chroot and build the srpm:
| |
| | |
| <pre>
| |
| mock --init
| |
| mock --copyin [SRPM] /
| |
| mock --shell bash
| |
| rpm -ivh [SRPM]
| |
| cd /builddir/build/SPECS
| |
| rpmbuild -bs --nodeps [SRPM]
| |
| rpm -qpiv /builddir/build/SRPMS/[SRPM]
| |
| </pre>
| |
| Check the <code>rpm</code> output for unexpanded macros (<code>%{foo}</code>) or missing information (when<code>%{?foo}</code> is expanded to the empty string). Even easier is to simply avoid macros in <code>Summary:</code> and <code>%description</code> unless they are defined in the current spec file.
| |
| | |
| === Improper use of %_sourcedir ===
| |
| Packages which use files itemized as Source# files, must refer to those files by their <code>Source#</code> macro name, and must not use <code>$RPM_SOURCE_DIR</code> or <code>%{sourcedir}</code> to refer to those files. See [[Packaging:RPM_Source_Dir]] for full details.
| |
| | |
| == %global preferred over %define ==
| |
| | |
| Use <code>%global</code> instead of <code>%define</code>, 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.
| |
| | |
| But when they are used in nested macro expansions (like in <code> %{!?foo: ... } </code> constructs, <code>%define</code> theoretically only lasts until the end brace (local scope), while <code>%global</code> definitions have global scope.
| |
| | |
| {{admon/note||In Fedora 12 and earlier, a minor bug in rpm caused the local macro definition to not be garbage collected unless other events forced rpm to. So the bug is seldom triggered but when it is it is difficult to diagnose the issue. Using <code>%global</code> by default helps to avoid creation of new latent bugs. [https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html Bugfix description]}}
| |
| | |
| {{Anchor|locales}}
| |
| | |
| == Handling Locale Files ==
| |
| | |
| If the package includes translations, add
| |
| <pre>
| |
| BuildRequires: gettext
| |
| </pre>
| |
| If you don't, your package could fail to generate translation files in the buildroot.
| |
| | |
| Fedora includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
| |
| <pre>
| |
| %find_lang %{name}
| |
| </pre>
| |
| In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
| |
| After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
| |
| <pre>
| |
| %files -f %{name}.lang
| |
| %defattr(-,root,root,-)
| |
| %{_bindir}/foobar
| |
| ...
| |
| </pre>
| |
| If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)
| |
| | |
| Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:
| |
| | |
| <pre>
| |
| ...
| |
| %prep
| |
| %setup -q
| |
| | |
| %build
| |
| %configure --with-cheese
| |
| make %{?_smp_mflags}
| |
| | |
| %install
| |
| make DESTDIR=%{buildroot} install
| |
| %find_lang %{name}
| |
| | |
| %clean
| |
| rm -rf %{buildroot}
| |
| | |
| %files -f %{name}.lang
| |
| %defattr(-,root,root,-)
| |
| %doc LICENSE README
| |
| %{_bindir}/foobar
| |
| | |
| %changelog
| |
| * Thu May 4 2006 Tom "spot" Callaway <tcallawa@redhat.com> 0.1-1
| |
| - sample spec that uses %%find_lang
| |
| | |
| </pre>
| |
| | |
| {{Anchor|whyfindlang}}
| |
| === Why do we need to use %find_lang? ===
| |
| | |
| Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.
| |
| | |
| * Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
| |
| * Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
| |
| <pre>
| |
| %{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
| |
| %{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
| |
| %{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
| |
| %{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
| |
| %{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
| |
| ...
| |
| </pre>
| |
| * As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.
| |
| | |
| Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.
| |
| | |
| {{Anchor|Timestamps}}
| |
| | |
| == Timestamps ==
| |
| When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. <code>cp -p</code> or <code>install -p</code>.
| |
| | |
| When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example <code>wget -N</code> or <code>curl -R</code>. To make the change global for wget, add this to your <code>~/.wgetrc</code>: <code>timestamping = on</code>, and for curl, add to your <code>~/.curlrc</code>: <code>-R</code>.
| |
| | |
| {{Anchor|parallelmake}}
| |
| == Parallel make ==
| |
| Whenever possible, invocations of <code>make</code> should be done as
| |
| <pre>
| |
| make %{?_smp_mflags}
| |
| </pre>
| |
| This generally speeds up builds and especially on SMP machines.
| |
| | |
| Do make sure, however, that the package builds cleanly this way as some make files do not support parallel building. Therefore you should consider adding
| |
| <pre>
| |
| %_smp_mflags -j3
| |
| </pre>
| |
| to your <code>~/.rpmmacros</code> file -- even on UP machines -- as this will expose most of these errors.
| |
| | |
| {{Anchor|Scriptlets}}
| |
| == Scriptlets ==
| |
| Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: [[Packaging:ScriptletSnippets]].
| |
| | |
| {{Anchor|reqprepost}}
| |
| === Scriptlets requirements ===
| |
| Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
| |
| <pre>
| |
| Requires(pre): ...
| |
| Requires(post): ...
| |
| </pre>
| |
| For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .
| |
| | |
| {{Anchor|ScriptletConditionals}}
| |
| === Running scriptlets only in certain situations ===
| |
| When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
| |
| <pre>
| |
| install erase upgrade reinstall
| |
| %pre 1 - 2 2
| |
| %post 1 - 2 2
| |
| %preun - 0 1 -
| |
| %postun - 0 1 -
| |
| </pre>
| |
| This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
| |
| <pre>
| |
| %preun
| |
| if [ $1 -eq 0 ] ; then
| |
| /sbin/chkconfig --del %{name}
| |
| fi
| |
| </pre>
| |
| See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.
| |
| | |
| {{Anchor|SciptletsWriteDirs}}
| |
| === Scriplets are only allowed to write in certain directories ===
| |
| Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix
| |
| | |
| {| border="1"
| |
| |-
| |
| | || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
| |
| |-
| |
| |%prep || yes || yes || no
| |
| |-
| |
| |%build || yes || yes || no
| |
| |-
| |
| |%install || yes || yes || yes
| |
| |-
| |
| |%check || yes || yes || no
| |
| |-
| |
| |%clean || yes || yes || yes
| |
| |}
| |
| | |
| Further clarification: That should hold true irrespective of the builder's uid.
| |
| | |
| === The %pretrans scriptlet ===
| |
| | |
| Note that the %pretrans scriptlet will, in the particular case of system installation, run before anything at all has been installed. This implies that it cannot have any dependencies at all. For this reason, %pretrans is best avoided, but if you must use it, the script must be written in Lua. See http://www.rpm.org/wiki/PackagerDocs/RpmLua for more information.
| |
| | |
| | |
| {{Anchor|ConditionalDependencies}}
| |
| == Conditional dependencies ==
| |
| If the spec file contains conditional dependencies selected based on presence of optional <code>--with(out) foo</code> arguments to <code>rpmbuild</code>, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the <code>rpmbuild</code> command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply.
| |
| | |
| {{Anchor|SeparateUserAccounts}}
| |
| == Build packages with separate user accounts ==
| |
| When building software, which you have not conducted a full security-audit on, protect sensitive data, such as your GPG private key, in a separate user account.
| |
| | |
| The same applies to reviewers/testers. Rebuild src.rpms in a separate account which does not have access to any sensitive data.
| |
| | |
| {{Anchor|RelocatablePackages}}
| |
| == Relocatable packages ==
| |
| The use of RPM's facility for generating relocatable packages is strongly discouraged. It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review.
| |
| | |
| | |
| {{Anchor|CodeVsContent}}
| |
| == Code Vs Content ==
| |
| It is important to make distinction between computer executable code and content.
| |
| While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissable.
| |
| | |
| The rule is this:
| |
| | |
| If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK.
| |
| | |
| Content still has to be reviewed for inclusion. It must have an open source compatible license, must not be legally questionable. In addition, there are several additional restrictions for content:
| |
| * Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn.
| |
| * Content should not be offensive, discriminatory, or derogatory. If you're not sure if a piece of content is one of these things, it probably is.
| |
| * All content is subject to review by FESCo, who has the final say on whether or not it can be included.
| |
| | |
| Some examples of content which is permissable:
| |
| | |
| * Package documentation or help files
| |
| * Clipart for use in office suites
| |
| * Background images (non-offensive, discriminatory, with permission to freely redistribute)
| |
| * Fonts (under an open source license, with no ownership/legal concerns)
| |
| * Game levels are not considered content, since games without levels would be non functional.
| |
| * Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable.
| |
| * Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered.
| |
| * Example files included with the source tarball are not considered content.
| |
| | |
| Some examples of content which are not permissable:
| |
| | |
| * Comic book art files
| |
| * Religious texts
| |
| * mp3 files (patent encumbered)
| |
| | |
| If you are unsure if something is considered approved content, ask on fedora-devel-list.
| |
| | |
| {{Anchor|FileAndDirectoryOwnership}}
| |
| == File and Directory Ownership ==
| |
| | |
| Your package should own all of the files that are installed as part of the %install process. Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the <code>filesystem</code> or <code>man</code> package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.
| |
| | |
| Directory ownership is a little more complex than file ownership. Packages must own all directories they put files in, except for:
| |
| * any directories owned by the <code>filesystem</code>, <code>man</code>, or other explicitly created <code>-filesystem</code> packages
| |
| * any directories owned by other packages in your package's natural dependency chain
| |
| | |
| In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory.
| |
| | |
| In all cases we are guarding against unowned directories being present on a system. Please see [[Packaging:UnownedDirectories]] for the details.
| |
| | |
| {{admon/important|Note on multiple ownership| Note that when co-owning directories, you <b>must</b> ensure that the ownership and permissions on the directory match in all packages that own it.}}
| |
| | |
| Here are examples that describe how to handle most cases of directory ownership.
| |
| | |
| === The directory is wholly contained in your package, or involves core functionality of your package ===
| |
| | |
| An example:
| |
| <pre>
| |
| gnucash places many files under the /usr/share/gnucash directory
| |
| </pre>
| |
| | |
| Solution: the <code>gnucash</code> package should own the <code>/usr/share/gnucash</code> directory
| |
| | |
| === The directory is also owned by a package implementing required functionality of your package ===
| |
| | |
| An example:
| |
| | |
| <pre>
| |
| pam owns the /etc/pam.d directory
| |
| gdm places files into /etc/pam.d
| |
| gdm depends on pam to function normally, and would Require: pam (either implicitly or explicitly) separate from the directory ownership.
| |
| </pre>
| |
| | |
| Solution: the <code>pam</code> package should own the <code>/etc/pam.d</code> directory, and <code>gdm</code> should <code>Require:</code> the <code>pam</code> package.
| |
| | |
| === The directory is owned by a package which is not required for your package to function ===
| |
| | |
| Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly.
| |
| | |
| An example:
| |
| | |
| <pre>
| |
| gtk-doc owns the /usr/share/gtk-doc/ directory
| |
| evolution puts files into /usr/share/gtk-doc/
| |
| evolution does not need gtk-doc in order to function properly.
| |
| Nothing in evolution's dependency chain owns /usr/share/gtk-doc/
| |
| </pre>
| |
| | |
| Solution: the <code>evolution</code> package should own the <code>/usr/share/gtk-doc</code> directory. There is no need to add an explicit Requires on gtk-doc solely for the directory ownership.
| |
| | |
| {{admon/important|An exception|Sometimes, it may be preferable for such directories to be owned by an "artificial filesystem" package, such as <code>mozilla-filesystem</code>. These packages are designed to be explicitly required when other packages store files in their directories, thus, in such situations, these packages should explicitly Require the artificial filesystem package and not multiply own those directories. Packagers should consider the number of affected directories and packages when determining whether to create artificial filesystem packages, and use their own best judgement to determine if this is necessary or not.}}
| |
| | |
| Another example:
| |
| | |
| <pre>
| |
| bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself.
| |
| git places files into /etc/bash_completion.d
| |
| bzr places files into /etc/bash_completion.d
| |
| </pre>
| |
| | |
| Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion.
| |
| {{admon/important|Rule of Thumb|When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?}}
| |
| | |
| === The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version ===
| |
| | |
| An example involving Perl modules:
| |
| | |
| Assume <code>perl-A-B</code> depends on <code>perl-A</code> and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.
| |
| The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the <code>perl-A</code> package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A. So the <code>perl-A-B</code> package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
| |
| | |
| == Users and Groups ==
| |
| | |
| Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate [[Packaging:UsersAndGroups]] document.
| |
| | |
| {{Anchor|WebApplications}}
| |
| == Web Applications ==
| |
| | |
| Web applications packaged in Fedora should put their content into /usr/share/%{name} and NOT into /var/www/. This is done because:
| |
| | |
| * /var is supposed to contain variable data files and logs. /usr/share is much more appropriate for this.
| |
| * Many users already have content in /var/www, and we do not want any Fedora package to step on top of that.
| |
| * /var/www is no longer specified by the Filesystem Hierarchy Standard
| |
| | |
| {{Anchor|Conflicts}}
| |
| == Conflicts ==
| |
| | |
| Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging:Conflicts]] .
| |
| | |
| Tools such as Alternatives and Environment Modules can also help prevent package conflicts.
| |
| | |
| === Alternatives ===
| |
| | |
| The "alternatives" tool provides a means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks. For full details on how to properly use alternatives, see [[Packaging:Alternatives]].
| |
| | |
| === Environment Modules ===
| |
| | |
| When there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. In such situations, use of Environment Modules can avoid conflicts. For full details on how to properly use Environment Modules, see [[Packaging:Environment Modules]].
| |
| | |
| == No External Kernel Modules ==
| |
| {{:Packaging:KernelModules}}
| |
| | |
| {{Anchor|NoFilesOrDirectoriesUnderSrv}}
| |
| == No Files or Directories under /srv ==
| |
| | |
| The [http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM FHS says] :
| |
| | |
| <pre>
| |
| "...no program should rely on a specific subdirectory structure of /srv existing
| |
| or data necessarily being stored in /srv. However /srv should always exist on FHS
| |
| compliant systems and should be used as the default location for such data.
| |
| | |
| Distributions must take care not to remove locally placed files in these
| |
| directories without administrator permission."
| |
| </pre>
| |
| | |
| /srv is a poorly implemented section of the FHS, and its intended use case is unclear. At this time, no Fedora package can have any directories or files under /srv.
| |
| | |
| It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data. The package simply must not own any directories or files in /srv.
| |
| | |
| {{Anchor|Bundling}}
| |
| == Bundling of multiple projects ==
| |
| Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.
| |
| | |
| {{Anchor|AvoidFontBundling}}
| |
| === Avoid bundling of fonts in other packages ===
| |
| Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging:FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
| |
| For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]].
| |
| | |
| == All patches should have an upstream bug link or comment ==
| |
| | |
| All patches in Fedora spec files '''SHOULD''' have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example:
| |
| | |
| <pre>
| |
| # http://bugzilla.gnome.org/show_bug.cgi?id=12345
| |
| Patch0: gnome-panel-fix-frobnicator.patch
| |
| </pre>
| |
| | |
| The above is perfectly acceptable; but if you prefer, a brief comment about what the patch does above can be helpful:
| |
| | |
| <pre>
| |
| # Don't crash with frobnicator applet
| |
| # http://bugzilla.gnome.org/show_bug.cgi?id=12345
| |
| Patch0: gnome-panel-fix-frobnicator.patch
| |
| </pre>
| |
| | |
| Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see [[PackageMaintainers/WhyUpstream| Why Upstream?]] ). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release.
| |
| | |
| === If upstream doesn't have a bug tracker ===
| |
| You can indicate that you have sent the patch upstream and any known status:
| |
| | |
| <pre>
| |
| # Sent upstream via email 20080407
| |
| Patch0: foobar-fix-the-bar.patch
| |
| </pre>
| |
| | |
| <pre>
| |
| # Upstream has applied this in SVN trunk
| |
| Patch0: foobar-fix-the-baz.patch
| |
| </pre>
| |
| | |
| === Fedora-specific (or rejected upstream) patches ===
| |
| It may be that some patches truly are Fedora-specific; in that case, say so:
| |
| | |
| <pre>
| |
| # This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK
| |
| Patch0: jna-jni-path.patch
| |
| </pre>
| |
| | |
| {{Anchor|Epochs}}
| |
| == Use of Epochs ==
| |
| The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.
| |
| | |
| === Epochs from Third Party Repositories ===
| |
| If a package to be imported is or previously was present in a publicly accessible repository, the packager can optionally include an Epoch tag equal to that of the most recent version of the third-party package.
| |
| | |
| == Symlinks ==
| |
| There are two ways of making a symlink, either as a relative link or an absolute link. In Fedora, neither method is required. Packagers should use their best judgement when deciding which method of symlink creation is appropriate.
| |
| | |
| === Relative Symlinks ===
| |
| A relative symlink is a symlink which points to a file or directory relative to the position of the symlink. For example, this command would create a relative symlink:
| |
| <pre>
| |
| ln -s ../..%{_bindir}/foo %{buildroot}/bin/foo
| |
| </pre>
| |
| | |
| Pros:
| |
| * Relative symlinks will point to the same file inside or outside of a chroot.
| |
| | |
| Cons:
| |
| * Much more complicated to create than absolute symlinks
| |
| * Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
| |
| * Relative symlinks may break when bind mounting or symlinking directories.
| |
| * Relative symlinks may make it more difficult to use rpm system macros.
| |
| | |
| === Absolute Symlinks ===
| |
| An absolute symlink is a symlink which points to an absolute file or directory path. For example, this command would create an absolute symlink:
| |
| <pre>
| |
| ln -s %{_bindir}/foo %{buildroot}/bin/foo
| |
| </pre>
| |
| | |
| Pros:
| |
| * Much easier to create than relative symlinks.
| |
| * Absolute symlinks work properly when bind mounting or symlinking directories.
| |
| * Absolute symlinks work well with rpm system macros.
| |
| | |
| Cons:
| |
| * Absolute symlinks may break when used with chroots.
| |
| | |
| == Man pages ==
| |
| Man pages are the traditional method of getting help on a unix system. Packages should contain man pages for all binaries/scripts. If it doesn't, work with upstream to add them. Sometimes, other distributions (notably Debian), have man pages for programs. You can use those as a starting point.
| |
| | |
| {{Anchor|ApplicationSpecificGuidelines}}
| |
| | |
| == Application Specific Guidelines ==
| |
| | |
| Some applications have specific guidelines written for them, located on their own pages in the Packaging: Namespace.
| |
| | |
| {{Anchor|EclipseGuidelines}}
| |
| === Eclipse ===
| |
| Guidelines for Eclipse plugin packages: [[Packaging:EclipsePlugins]]
| |
| | |
| {{Anchor|EmacsGuidelines}}
| |
| === Emacs ===
| |
| Guidelines for Emacs/X-Emacs packages: [[Packaging:Emacs]]
| |
| | |
| {{Anchor|FontGuidelines}}
| |
| === Fonts ===
| |
| Guidelines for font packages: [[Packaging:FontsPolicy]]
| |
| | |
| {{Anchor|FortranGuidelines}}
| |
| === Fortran ===
| |
| Guidelines for Fortran packages: [[Packaging:Fortran]]
| |
| | |
| {{Anchor|GlobusGuidelines}}
| |
| | |
| === Globus Toolkit ===
| |
| Guidelines for packaging pieces of the Globus Toolkit [[Packaging:Globus]]
| |
| | |
| {{Anchor|HaskellGuidelines}}
| |
| === Haskell ===
| |
| Guidelines for Haskell packages: [[Packaging:Haskell]]
| |
| | |
| {{Anchor|JavaGuidelines}}
| |
| === Java ===
| |
| Guidelines for java packages: [[Packaging:Java]]
| |
| | |
| {{Anchor|LispGuidelines}}
| |
| === Lisp ===
| |
| Guidelines for lisp packages: [[Packaging:Lisp]]
| |
| | |
| {{Anchor|MonoGuidelines}}
| |
| === Mono ===
| |
| Guidelines for Mono packages: [[Packaging:Mono]]
| |
| | |
| {{Anchor|MPIGuidelines}}
| |
| === MPI ===
| |
| Guidelines for MPI packages: [[Packaging:MPI]]
| |
| | |
| {{Anchor|OCamlGuidelines}}
| |
| === OCaml ===
| |
| Guidelines for OCaml packages: [[Packaging:OCaml]]
| |
| | |
| {{Anchor|OpenOffice.orgGuidelines}}
| |
| === OpenOffice.org ===
| |
| Guidelines for OpenOffice.org extension packages: [[Packaging:OpenOffice.orgExtensions]]
| |
| | |
| {{Anchor|PerlGuidelines}}
| |
| === Perl ===
| |
| Guidelines for Perl packages: [[Packaging:Perl]]
| |
| | |
| {{Anchor|PHPGuidelines}}
| |
| === PHP ===
| |
| Guidelines for PHP packages: [[Packaging:PHP]]
| |
| | |
| {{Anchor|PythonGuidelines}}
| |
| === Python ===
| |
| Guidelines for Python addon modules: [[Packaging:Python]]
| |
| | |
| {{Anchor|RGuidelines}}
| |
| === R ===
| |
| Guidelines for R module packages: [[Packaging:R]]
| |
| | |
| {{Anchor|RubyGuidelines}}
| |
| === Ruby ===
| |
| Guidelines for Ruby packages: [[Packaging:Ruby]]
| |
| | |
| {{Anchor|SugarGuidelines}}
| |
| === Sugar ===
| |
| Guidelines for Sugar Activity packages: [[Packaging:SugarActivityGuidelines]]
| |
| | |
| {{Anchor|TclGuidelines}}
| |
| === Tcl/Tk ===
| |
| Guidelines for Tcl/Tk extension packages: [[Packaging:Tcl]]
| |
| {{Anchor|TclGuidelines}}
| |
| | |
| === Wordpress ===
| |
| Guidelines for Wordpress extension packages: [[Packaging:WordPress plugin packaging guidelines]]
| |
| | |
| [[Category:Packaging guidelines]]
| |