--- guidelines.wiki.orig 2008-06-23 15:56:05.000000000 +0200
+++ guidelines.wiki 2008-06-23 15:55:53.000000000 +0200
@@ -132,12 +132,11 @@
* 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 ==
-The ''!BuildRoot'' value MUST be below %{_tmppath}/
and MUST contain at least %{name}
, %{version}
and %{release}
. It may invoke mktemp
since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''!BuildRoot''.
+The ''BuildRoot'' value MUST be below %{_tmppath}/
and MUST contain at least %{name}
, %{version}
and %{release}
. It may invoke mktemp
since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''.
-The ''recommended'' values for the ''!BuildRoot'' tag are (in descending order of preference) :
+The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -148,7 +147,7 @@ {{Anchor|PreppingBuildRootForInstall}} === Prepping BuildRoot For %install === -It is important to properly prepare the !BuildRoot in the%install
section of your package before it is used. Every Fedora package MUST have an %install section that begins with either: +It is important to properly prepare the BuildRoot in the%install
section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:%install @@ -162,7 +161,7 @@ rm -rf $RPM_BUILD_ROOT-This is to ensure that the !BuildRoot will be created fresh during the%install
section. +This is to ensure that the BuildRoot will be created fresh during the%install
section. {{Anchor|Requires}} == Requires == @@ -176,7 +175,7 @@ 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 +rpm --query --qf "%{EPOCH}\n" foo 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: @@ -353,8 +352,8 @@ * 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: -1. '''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 Build''''''Require the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. -2. '''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: +# '''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 BuildRequire 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:%package devel Provides: foo-static = %{version}-%{release} @@ -435,7 +434,7 @@ {{Anchor|Initscripts}} == Initscripts == -Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: [[Packaging/SysVInitScript]] +Currently, SystemV-style initscripts are supported in Fedora, but Fedora is heading to the Upstart Init Daemon. There are detailed guidelines for SysV-style initscripts here: [[Packaging/SysVInitScript]] {{Anchor|desktop}} == Desktop files == @@ -502,7 +501,6 @@ 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]] ).