Denotes the dependency must be present right after the package is is installed, and is used a strong ordering hint to break possible dependency loops. A post-dependnecy is free to be removed once the install-transaction completes. Denotes the dependency must be present in before the package is is removed, and is used a strong ordering hint to break possible dependency loops. Denotes the dependency must be present right after the package is is removed, and is used a strong ordering hint to break possible dependency loops.
Denotes the dependency must be present before the transaction starts, and cannot be satisified by added packages in a transaction. As such, it does not affect transaction ordering. A pretrans-dependency is free to be removed after the install-transaction completes.
Denotes the dependency must be present at the end of transaction, ie cannot be removed during the transaction. A posttrans-dependency is free to be removed after the the install-transaction completes. Denotes a scriptlet interpreter dependency, usually added automatically by rpm. Used as a strong ordering hint for breaking dependency loops.
Typical use-cases would be meta-packages and sub-package cross-dependencies whose purpose is just to ensure the sub-packages stay on common version. As noted above, dependencies qualified as install-time only pretrans , pre , post , posttrans or combination of them can be removed after the installation transaction completes if there are no other dependencies to prevent that.
This is a common source of confusion. Capabilities this package conflicts with, typically packages with conflicting paths or otherwise conflicting functionality.
Package is not buildable on architectures listed here. Used when software is portable across most architectures except some, for example due to endianess issues. Package is only buildable on architectures listed here. Specifies the architecture which the resulting binary package will run on. Typically this is a CPU architecture like sparc, i Typical platform independent packages are html, perl, python, java, and ps packages.
As a special case, BuildArch: noarch can be used on sub-package level to allow eg. Specify prefixes this package may be installed into, used to make packages relocatable. Very few packages are. Colon separated lists of path postfixes that are removed from the end of file names when adding those files to the package.
Used on sub-package level. Used for creating sub-packages with conflicting files, such as different variants of the same content eg minimal and full versions of the same software. Conditionalizing Source: or Patch: tags by architecture causes the contents of the source package to differ depending on the architecture which was used to build it. The best solution is to write patches which simply work on all architectures. For example:.
Fedora follows the Filesystem Hierarchy Standard with regards to filesystem layout, with exceptions noted below. The FHS defines where files should be placed on the system.
The Filesystem Hierarchy Standard does not include any provision for libexecdir, but Fedora packages MAY store appropriate files there. However, you should be sure that the sub package that they are in does not have other content that would be considered eligible for multilib.
If this is not the case for the files you wish to do this in for your package or you are just unsure, ask FESCo for an explicit multilib exemption. The FHS says :. Modifying files in home directories that are thus configured will have negative effects in both of these situations. The package simply must not do this out of the box. The Chromium support MAY be in a different subpackage.
If Chrome in the future allows a more standard directory to be used for this purpose, this exception will be removed. So an rpm which specified:. As a packager you may need to pay attention to where other packages expect to find your files. If you feel that there is some historical confusion as to which directory a program is placed in, you can use a Virtual Provides to list the alternate path.
For instance:. If you are a packager who uses file dependencies to Require the proper dependencies then you may need to make sure that the file dependencies are pointing to the location that the packager of that file specified to rpm.
Run rpmlint on binary and source rpms to examine them for common errors, and fix them unless rpmlint is wrong, which can happen, too. Note that rpmlint will perform additional checks if given the name of an installed package.
For example, dnf install foo A community-maintained page on rpmlint issues can be found here. The Source: tags document where to find the upstream sources for the package. RPM can automatically determine dependencies for most compiled libraries and for some scripting languages such as Perl.
Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. If a versioned dependency would be satisfied by a version present in three previous Fedora releases then a versioned dependency is not needed and a regular unversioned dependency SHOULD be used instead.
Otherwise the dependency will not function as expected. Requires MUST be used if the dependency is required for the software to function correctly. See Packaging:WeakDependencies for guidelines on using those dependency types. RPM gives you the ability to depend on arbitrary files or directories instead of packages. Please also note that it is not uncommon for multiple packages to provide the same directory.
Explicit Requires are Requires added manually by the packager in the spec file. Packages must not contain unnecessary explicit Requires on libraries. Modern package management tools are capable of resolving such dependencies to determine the required packages in many cases.
This can be a problem if a library has added features over the course of time without backwards incompatibilities that would cause SONAMES to be changed.
This can lead to a case where the user has an old version of a library installed, the new version of the library with new ABI is built in Fedora and an application using that ABI is built.
If the user just attempts to install or update that one application without also updating the library, the application will install fine because the SONAME dependency is satisfied but will fail when run because the library installed on the system is missing features it needs.
Although you do need to add explicit library dependencies to keep this from occurring, there are drawbacks to manually specifying this in all your packages. For example, Fedora packages are only required to retain historical provides for two full release cycles.
When explicit library Requires are necessary, explicit library dependencies should typically be arch-specific unless the packages involved are noarch and there should be a spec file comment justifying it:. Packagers should revisit an explicit dependency as appropriate to avoid it becoming inaccurate and superfluous.
It is important that your package list all necessary build dependencies using the BuildRequires: tag. For instance, if you did this:. Fedora packages which use pkg-config to build against a library e. 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.
The reason is that those requirements get "serialized" into the resulting source RPM, i. 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.
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. Packagers should be careful how they use trademarks in Summary or Description.
There are a few rules to follow:. 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:. When in doubt, try to leave the trademark out. Any relevant documentation included in the source distribution should be included in the package in the proper documentation directory.
Irrelevant documentation includes build instructions, the omnipresent INSTALL file containing generic build instructions, or example, and documentation for non-Linux systems, e. Also pay attention about which subpackage you include documentation in. For example API documentation belongs in the -devel subpackage, not the main one. Files marked as documentation must not cause the package to pull in more dependencies than it would without the documentation.
The software must function properly and with unchanged functionality if those files are modified, removed or not installed at all. Although license files are documentation, they are treated specially including using a different tag. Please see Licensing Guidelines for how to handle them. This separately packaged documentation MUST correspond to the version of the packaged software. In other words, if a new release of the software includes changes to the documentation, then the documentation package MUST also be updated.
But if the new version of the software does not include documentation changes, then you MAY choose not to update the documentation package. 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 packagers, 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.
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. If you wish to "scramble" or "obfuscate" your email address in the changelog, you may do so, provided that it is still understandable by humans. 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:. 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. You can do this any number of times, until you actually build 1. 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:. It is also occasionally possible to find pages created by other distributions, or to use the output of the help2man program; those are often useful as a starting point.
When installing man pages, note that RPM will re-compress them into its preferred format. Fedora packages should default to using gcc as the compiler for all languages that gcc supports or clang if upstream does not support building with gcc.
However, if there is a good technical reason, packagers may choose not to use the default compiler. Examples of valid technical reasons to not use the default compiler, include but are not limited to:. The packager needs to disable a compiler feature e.
LTO in order for the default compiler to correctly compile their package. Packagers choosing to use a non-default compiler should document the reason for this decision in a comment in the spec file. If a packager wants to use conditional macros in a spec file to make it easier to switch between two different compilers, then the following macros names should be used:.
Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. 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.
Overriding these flags for performance optimizations for instance, -O3 instead of -O2 is generally discouraged. If you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis. There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for some programs.
PIE adds security to executables by composing them entirely of position-independent code. Position-independent code PIC is machine instruction code that executes properly regardless of where in memory it resides. PIE allows Exec Shield to use address space layout randomization to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks.
Your package is long running. Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo 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.
Fedora packages must be designed with a logical separation of files. Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is done to minimize the install footprint for users.
There are some types of files which almost always belong in a -devel package:. Static library files when the package does not provide any matching shared library files.
See Packaging Static Libraries for more information about this scenario. Unversioned shared system library files, when a matching versioned shared system library file is also present.
For example, if your package contains:. This means that it belongs in a -devel package. When a shared library file is only provided in an unversioned format, the packager should ask upstream to consider providing a properly versioned library file.
However, in such cases, if the shared library file is necessary for users to run programs linked against it, it must go into the base package. If upstream versions the shared library file at a future point, packagers must be careful to move to the versioned layout described above. As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries.
These files are usually plugins or modular functionality specific to an application, and are not located in the ld library paths or cache. In these cases, the unversioned shared objects do not need to be placed in a -devel package. When in doubt as to whether a file belongs in the base package or in -devel, packagers should consider whether the file is necessary to be present for a user to use or execute the functionality in the base package properly, or if it is only necessary for development.
If it is only necessary for development, it must go into a -devel package. As with all Fedora Packaging Guidelines, it is recognized that there are unique situations that fall outside of the boundaries of this model. Should you come across such a case, please open a ticket with the Fedora Packaging Committee and explain it to us so that we can extend the Guidelines to address it.
The placement of pkgconfig. 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. Subpackages are often extensions for their base package and in that case they should require their base package.
Devel packages are an example of a package that must require their base packages using a fully versioned dependency. When a subpackage requires the base package, it must do so using a fully versioned arch-specific for non-noarch packages dependency:. It is not necessary to call ldconfig when installing shared libraries.
Otherwise, when the library bumps its SONAME as part of an update, this change might remain unnoticed and cause problems like broken dependencies see the relevant Updates Policy section for further information.
However, if the use of globs is deemed useful by the packager - for example, if the Y and Z parts of a library named libfoo. Z change frequently, using something like libfoo.
In cases where upstream ships unversioned. If that fails due to unwilling or unresposive upstream, the packager may start versioning downstream but this must be done with caution and ideally only in rare cases.
Under no circumstances should the unversioned library be shipped in Fedora. The n should initially be a small integer for instance, "1". Using multiple digits helps us avoid potential future conflicts. When new versions of the library are released, you should use an ABI comparison tool to check for ABI differences in the built shared libraries. If it detects any incompatibilities, bump the n number by one. When running an executable linked to shared object with SONAME field, the dynamic linker checks for this field instead of filename to determine the object with which it should link.
This allows developers to simply link against the unversioned library symlink and the dynamic linker will link against the correct object. 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 can be passed as an option to gcc like this:. Libtool archives, foo. Packages using libtool will install these by default even if you configure with --disable-static , so they may need to be removed before packaging. In most cases it is fairly easy to work with upstream to fix these issues. 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. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. Static libraries only.
Packages which explicitly need to link against the static version MUST BuildRequire: foo-static , so that the usage can be tracked. Since the code is generated during compile time, they act just like static libraries and need to be treated as such. Packages which use the header library must BuildRequire: foo-static , so that the usage can be tracked. This ensures that any tests are run on all architectures, and makes it possible to detect whether the build or install process has modified the headers based on the build architecture.
When the contents of subpackages, including the -devel package, are actually architecture-independent, they may still be marked noarch.
If it is necessary to link against. Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. All packages whose upstreams allow them to be built against system libraries MUST be built against system libraries. Build scripts may need to be patched to deal with this situation. Whenever possible, the patch should conditionalize the use of the bundled libraries, so that the patch can be sent upstream for consideration.
All packages whose upstreams have no mechanism to build against system libraries MAY opt to carry bundled libraries, but if they do, they MUST include an indication of what they bundle. This provides a mechanism for locating libraries with bundled code which can, for example, assist in locating packages which may have particular security vulnerabilities.
To indicate an instance of bundling, first determine the name and version of the bundled library:. If the bundled package also exists separately in the distribution, use the name of that package. Otherwise consult the Naming Guidelines to determine an appropriate name for the library as if it were entering the distribution as a separate package. Use the Versioning Guidelines to determine an appropriate version for the library, if possible.
If the library has been forked from an upstream, use the upstream version that was most recently merged in or rebased onto, or the version the original library carried at the time of the fork. In addition to indicating bundling in this manner, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries.
If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the Provides: above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the Provides: above.
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. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld. 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.
When a program installs internal libraries they are often not installed in the system path. 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. If you are storing a library in a non-standard location e. As far as the spec file goes, what about: Requires: db4.
Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name.
Email Required, but never shown. The Overflow Blog. Podcast Making Agile work for data science. Stack Gives Back Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually.
0コメント