Differences

This shows you the differences between two versions of the page.

--- rpm [2012/04/12 18:34] – [RPM Spec File Information] k2patel
+++ rpm [2020/08/10 02:35] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== RPM ======
+* [[ Python packages to rpm ]]
 Package management system few tips / trick to build / modify / work with packages. \\
 Many hints information taken from original site [[http://rpm.org/ | RPM]]
+==== RPM Common Command ====
+^ Syntax ^Description^
+| rpm -ivh {rpm-file} | Install the package |
+| rpm -Uvh {rpm-file} | Upgrade package |
+| rpm -ev {package} | Erase/remove/ an installed package |
+| rpm -ev --nodeps {package} | Erase/remove/ an installed package without checking for dependencies |
+| rpm -qa | Display list all installed packages |
+| rpm -qi {package} | Display installed information along with package version and short description |
+| rpm -qf {/path/to/file} | Find out what package a file belongs to i.e. find what package owns the file |
+| rpm -qc {pacakge-name} | Display list of configuration file(s) for a package |
+| rpm -qcf {/path/to/file} | Display list of configuration files for a command |
+| rpm -qa --last | Display list of all recently installed RPMs |
+| rpm -qpR {.rpm-file} | Find out what dependencies a rpm file has |
+| rpm -qR {package}	| ::: |
+| rpm -qR bash | ::: |
 ==== How to Print .spec file from RPM ====
@@ Line 125: / Line 143: @@
 </code>
+==== Something i come across ====
+If you wanna override marco from OS you can define value at ''top'' of the spec file.
+<code bash>
+%define _mandir /usr/man
+</code>
 ==== Sample RPM ====
 <code bash | sample.spec>
@@ Line 216: / Line 239: @@
 [[http://rpm.org/wiki/Docs#PackagerDocumentation | RPM Official]]
+==== Scriptlets ====
+Normally, rpm has scriptlets inside the spec file that are
+ran at install time.  These are:
+<code bash>
+	%pre              - Run before rpm files are installed.
+	%post             - Run after rpm files are installed.
+	%preun            - Run before rpm files are erased.
+	%postun           - Run after rpm files are erased.
+ 	%triggerin        - Install trigger.
+	%triggerun        - uninstall trigger
+	%triggerpostun    - postuninstall trigger.
+</code>
+The scripts are normally bash scripts, but you can change the interpreter
+with the -p option.
+Also, as they are bash scripts you can call external scripts from these.
 ==== General RPM Command ====
@@ Line 223: / Line 263: @@
 </code>
+==== Error on Building ====
+=== module: command not found ===
+Try running following command and then execute rpmbuild will resolve the issue.
+<code bash>
+source /etc/profile.d/modules.sh
+</code>
 ==== MOCK ====
@@ Line 267: / Line 314: @@
 </code>
+== Building SRPM ==
+<code bash>
+mock -r epel-6-x86_64 --spec icinga-web.spec --sources=../SOURCES/ --resultdir=../RPMS/ --buildsrpm
+</code>
 ==== Copying Files ====
 <note important>Dont scratch over --copyin check spelling one more time</note>
@@ Line 292: / Line 343: @@
 In general case result will be stored in '/var/lib/mock/epel-5-x86_64/result/'
-==== RPM Spec File Information ====
+==== SPEC file Overview ====
 This is mostly from following URL [[http://fedoraproject.org/wiki/How_to_create_an_RPM_package | Fedora Project]]
 <code text>
-SPEC file overview
 Other useful guides:
@@ Line 387: / Line 437: @@
 See the %prep section below for more.
-%build: Script commands to "build" the program (e.g. to compile it) and get it ready for installing. The program should come with instructions on how to do this. See the %build section below for more.
+%build: Script commands to "build" the program (e.g. to compile it) and get it ready for installing.
+The program should come with instructions on how to do this. See the %build section below for more.
-%check: Script commands to "test" the program. This is run between the %build and %install procedures, so place it there if you have this section. Often it simply contains "make test" or "make check". This is separated from %build so that people can skip the self-test if they desire.
+%check: Script commands to "test" the program. This is run between the %build and %install procedures,
+so place it there if you have this section. Often it simply contains "make test" or "make check".
+This is separated from %build so that people can skip the self-test if they desire.
-%install: Script commands to "install" the program. The commands should copy the files from the BUILD directory %{_builddir} into the buildroot directory, %{buildroot}. See the %install section below for more.
+%install: Script commands to "install" the program.
+The commands should copy the files from the BUILD directory %{_builddir} into the buildroot directory,
+%{buildroot}. See the %install section below for more.
-%clean: Instructions to clean out the build root. Note that this section is now redundant in Fedora and is only necessary for EPEL. Typically this contains only:
+%clean: Instructions to clean out the build root. Note that this section is now redundant in Fedora and is only necessary for EPEL.
+Typically this contains only:
 rm -rf %{buildroot}
@@ Line 415: / Line 471: @@
 Do not create a "relocatable" package; they don't add value in Fedora and make things more complicated.
 </code>
+==== SPEC file sections explained ====
+<code text>
+ %prep section
+The %prep section describes how to unpack the compressed packages so that they can be built.
+Typically, this includes the "%setup" and "%patch" commands with reference to the Source0
+(and Source1 etc.) lines. See the Maximum RPM section on %setup and %patch for more details.
+The %{patches} and %{sources} macros are available since RPM 4.4.2 and are useful
+if you have a large list of patches or sources:
+for p in %{patches}; do
+    ...
+done
+However, keep in mind that using these will make your SPEC incompatible with RPMS
+used in RHEL and other RPM-based dirstributions.
+ %prep section: %setup command
+The "%setup" command unpacks a source package. Switches include:
+-q : Suppress unecessary output. This is commonly used.
+-n name : If the Source tarball unpacks into a directory whose name is not the RPM name,
+this switch can be used to specify the correct directory name. For example,
+if the tarball unpacks into the directory FOO, use "%setup -q -n FOO".
+-c name : If the Source tarball unpacks into multiple directories instead of a single directory,
+this switch can be used to create a directory named name and then unpack into it.
+There are more %spec options if you are unpacking multiple files,
+which is primarily useful if you are creating subpackages (see below). The key ones are:
+-a number	 Only unpack the Source directive of the given number after changing directory
+(e.g. "–a 0" for Source0).
+-b number	 Only unpack the Source directive of the given number before changing directory
+(e.g. "–b 0" for Source0).
+-D	 Do not delete the directory before unpacking.
+-T	 Disable the automatic unpacking of the archives.
+ %prep section: %patch commands
+The "%patch0" command applies Patch0 (and %patch1 applies Patch1 etc.).
+Patches are the normal method of making necessary changes to the source code for packaging.
+The usual "-pNUMBER" option applies, which passes that argument onto the program patch.
+Patch file names often look like "telnet-0.17-env.patch",
+which is the format %{name} - %{version} - REASON.patch" (though sometimes version is omitted).
+Patch files are typically the result of "diff -u";
+if you do this from the subdirectory of ~/rpmbuild/BUILD then you won't have to specify a -p level later.
+This is a typical procedure for creating a patch for a single file:
+cp foo/bar foo/bar.orig
+vim foo/bar
+diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch
+If editing many files, one easy method is to copy the
+whole subdirectory underneath BUILD and then do subdirectory diffs.
+After you have changed directory to "~rpmbuild/BUILD/NAME", do the following:
+cp -pr ./ ../PACKAGENAME.orig/
+... many edits ...
+diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/NAME.REASON.patch
+If you edit many files in one patch, you can also copy the original files
+ using some consistent ending such as ".orig" before editing them.
+Then, you can use "gendiff" (in the rpm-build package) to create a patch with the differences.
+Try to ensure that your patch match the context exactly.
+The default "fuzz" value is "0", requiring matches to be exact.
+You can work around this by adding "%global _default_patch_fuzz 2"
+to revert to the value found in older versions of RPM in Fedora,
+but it is generally recommended to avoid doing this.
+As explained in Packaging/PatchUpstreamStatus,
+all patches should have a comment above them in the SPEC file about their upstream status.
+This should document the upstream bug/email that includes it (including the date).
+If it is unique to Fedora, you should mention why it is unique.
+The Fedora Project tries not to deviate from upstream;
+see PackageMaintainers/WhyUpstream for the importance of this.
+ %prep section: Unmodified files
+Sometimes, one or more of the Source files do not need to be uncompressed.
+You can "prep" those into the build directory like this (where SOURCE1 refers to the relevant Source file):
+cp -p %SOURCE1 .
+ %build section
+The "%build" section is sometimes complicated;
+here you configure and compile/build the files to be installed.
+Many programs follow the GNU configure approach (or some variation).
+By default, they will install to a prefix of "/usr/local", which is reasonable for unpackaged files.
+However, since you are packaging it, change the prefix to "/usr".
+Libraries should be installed to either /usr/lib or /usr/lib64 depending on the architecture.
+Since GNU configure is so common, the macro "%configure" can be used to automatically
+invoke the correct options (e.g. change the prefix to /usr). Some variation of this often works:
+ %configure
+ make %{?_smp_mflags}
+To override makefile variables, pass them as parameters to make:
+make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
+More more information, see "GNU autoconf, automake, and libtool"
+ and
+"Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf" by Stefan Hundhammer.
+Some programs use cmake. See Packaging/cmake.
+ %check section
+If self-tests are available, it is generally a good idea to include them.
+They should be placed in the %check section (which immediately follows the %build section)
+instead of within the %build section itself, so that they can be easily skipped when necessary.
+Often, this section contains:
+make test
+ %install section
+This section involves script commands to "install" the program,
+copying the relevant files from %{_builddir} to %{buildroot}
+(which usually means from ~/rpmbuild/BUILD to ~/rpmbuild/BUILDROOT)
+and creating directories inside %{buildroot} as necessary.
+Some of the terminology can be misleading:
+The "build directory", also known as %{_builddir} is not the same as the "build root",
+also known as %{buildroot}. Compilation occurs in the former directory,
+while files to be packaged are copied from the former to the latter.
+During the %build section, the current directory will start at %{buildsubdir},
+which is the subdirectory within %{_builddir} that was created during %prep stage.
+This is usually something like ~/rpmbuild/BUILD/%{name}-%{version}.
+The %install section is not run when the binary RPM package is installed by the end-user,
+but is only run when creating a package.
+Normally, some variation of "make install" is performed here:
+%install
+rm -rf %{buildroot}
+make DESTDIR=%{buildroot} install
+Removal of %{buildroot} is no longer necessary, except for EPEL 5.
+Ideally you should use DESTDIR=%{buildroot} if the program supports it,
+as it redirects file installations to the specified directory and is exactly
+what we want to happen during the %install section.
+If the program does not support DESTDIR (and only if),
+you can workaround it in one of several (inferior) ways:
+Patch the makefile so that is supports DESTDIR.
+Create directories inside DESTDIR where necessary and submit the patch upstream.
+Use the "%makeinstall" macro. This method might work, but can lead to subtle failures.
+It expands to something like
+"make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install",
+which can result in some programs failing to work properly.
+Create directories inside %{buildroot} where necessary.
+Consider using the auto-destdir package. This requires
+"BuildRequires: auto-destdir", and changing "make install" to "make-redir DESTDIR=%{buildroot} install".
+This only works well if the installation uses only certain common commands to install files,
+like cp and install.
+Perform the installation by hand. This would involve creating the necessary directories under
+%{buildroot} and copying files from %{_builddir} to %{buildroot}.
+Be especially careful with updates, which often contain new or changed filenames.
+An example of this procedure:
+%install
+rm -rf %{buildroot}
+mkdir -p %{buildroot}%{_bindir}/
+cp -p mycommand %{buildroot}%{_bindir}/
+As noted in Packaging:Guidelines#Timestamps,
+try to preserve timestamps if the makefile lets you override commands:
+make INSTALL="install -p" CP="cp -p" DESTDIR=%{buildroot} install
+ %files section
+This section declares which files and directories are owned by the package,
+and thus which files and directories will be placed into the binary RPM.
+ %files basics
+The %defattr set the default file permissions, and is often found at the start of the %files section.
+Note that this is no longer necessary unless the permissions need to be altered. The format of this is:
+%defattr(<file permissions>, <user>, <group>, <directory permissions>)
+The fourth parameter is often omitted.
+Usually one uses %defattr(-,root,root,-), where "-" uses the default permissions.
+You should then list all the files and directories to be owned by the package.
+Use macros for directory names where possible,
+which can be viewed at Packaging:RPMMacros (e.g. use %{_bindir}/mycommand instead of /usr/bin/mycommand).
+If the pattern begins with a "/" (or when expanded from the macro)
+then it is taken from the %{buildroot} directory. Otherwise,
+the file is presumed to be in the current directory (e.g. inside %{_builddir}
+(such as documentation files that you wish to include).
+If your package only installs a single file /usr/sbin/mycommand,
+then the %files section can simply be:
+%files
+%{_sbindir}/mycommand
+To make your package less sensitive to upstream changes,
+declare all files within a directory to be owned by the package with a pattern match:
+%{_bindir}/*
+To include a single directory:
+%{_datadir}/%{name}/
+Note that %{_bindir}/* does not claim that this package owns the /usr/bin directory,
+but only the files contained within. If you list a directory,
+then you are claiming that the package owns that directory and
+all files and subdirectories contained within. Thus, do not list %{_bindir} and
+be careful of directories that may be shared with other packages.
+An error will occur if:
+a pattern match does not match any file or directory
+a file or directory is listed or matched more than once
+a file or directory in the %{buildroot} has not been listed
+It is also possible to exclude files from a previous match by using the %exclude glob.
+This can be useful for including almost all of the files included by a different pattern match,
+but note that it will also fail if it does not match anything.
+ %files prefixes
+You may need to add one or more prefixes to lines in the %files section;
+seperate them with a space. See Max RPM section on %files directives.
+Usually, "%doc" is used to list documentation files within
+%{_builddir} that were not copied to %{buildroot}.
+A README and INSTALL file is usually included.
+They will be placed in the directory /usr/share/doc/%{name}-%{version},
+whose ownership does not need to be declared.
+Note: If specifying a %doc entry,
+then you can't copy files into the documentation directory during the %install section.
+If, for example, you want an "examples" subdirectory within the documentation directory,
+don't use %doc, but instead create the directories and copy files over manually
+ into %{buildroot}%{_defaultdocdir}/%{name}-%{version} during the %install section.
+They will be correctly marked as documentation.
+Make sure you include %{_defaultdocdir}/%{name}-%{version}/ as an entry in the %files section.
+Configuration files should be placed in /etc and are normally specified like this
+(which makes sure user changes aren't overwritten on update):
+%config(noreplace) %{_sysconfdir}/foo.conf
+If the update uses a non-backwards-compatible configuration format, then specify them like this:
+%config %{_sysconfdir}/foo.conf
+"%attr(mode, user, group)" can be used for finer control over permissions,
+where a "-" means use the default:
+%attr(0644, root, root) FOO.BAR
+If a file is in particular natural language, use %lang to note that:
+%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
+Programs using Locale files should follow the recommended method of handling i18n files:
+find the filenames in the %install step:  %find_lang ${name}
+add the required build dependencies: BuildRequires: gettext
+use the found filenames: %files -f ${name}.lang
+These prefixes are not valid in Fedora: %license and %readme.
+ %files and Filesystem Hierarchy Standard (FHS)
+You should follow the Filesystem Hierarchy Standard (FHS).
+Executables go in /usr/bin, global configuration files go in /etc,
+libraries go into /usr/lib (or /usr/lib64) and so on.
+There is one exception: executables that should not normally be executed
+directly by users or administrators should go in a subdirectory of /usr/libexec,
+which is referred to as %{_libexecdir}/%{name}.
+Do not install files into /opt or /usr/local.
+Unfortunately, many programs do not follow the FHS by default.
+In particular, architecture-independent libraries get placed in /usr/lib instead of /usr/share.
+The former is for architecture-dependent libraries,
+while the latter is for architecture-independent libraries,
+which means that systems with different CPU architectures can share /usr/share.
+There are many exceptions in Fedora (such as Python and Perl),
+but Fedora applies this rule more strictly than some distributions.
+rpmlint will generally complain if you put anything other than ELF files into /usr/lib.
+ %files example
+Here's a simple example of a %files section:
+%files
+%doc README LICENSE
+%{_bindir}/*
+%{_sbindir}/*
+%{_datadir}/%{name}/
+%config(noreplace) %{_sysconfdir}/*.conf
+Finding duplicates
+You can list any duplicates of two binary packages by doing:
+cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture
+rpm -qlp PACKAGE1.*.rpm | sort > ,1
+rpm -qlp PACKAGE2.*.rpm | sort > ,2
+comm -12 ,1 ,2
+Scriptlets
+When an end-user installs the RPM, you may want some commands to be run.
+This can be achieved through scriptlets. See Packaging/ScriptletSnippets.
+Scriptlets can be run:
+before (%pre) or after (%post) a package is installed
+before (%preun) or after (%postun) a package is uninstalled
+at the start (%pretrans) or end (%posttrans) of a transaction
+For example, every binary RPM package that stores shared library files
+in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
+If the package has multiple subpackages with libraries,
+each subpackage should also perform the same actions.
+%post -p /sbin/ldconfig
+%postun -p /sbin/ldconfig
+If only running a single command, then the "-p" option runs the adjacent
+command without invoking the shell. However, for several commands,
+omit this option and include the shell commands beneath.
+If you run any programs within the scriptlets, then you must specify any
+requirements in the form "Requires(CONTEXT)" (e.g. Requires(post)).
+%pre, %post, %preun, and %postun provide the argument $1,
+which is the number of packages of this name which will be left on the system
+when the action completes. Don't compare for equality with 2,
+but instead check if they are greater than or equal to 2.
+For %pretrans and %posttrans, $1 is always 0.
+For example, if the package installs an info manual,
+then the info manual index must be updated with install-info from the info package.
+Firstly, there is no guarantee that the info package will be available unless
+we explicitly declare it as required, and secondly,
+we don't want to fail completely if install-info fails:
+Requires(post): info
+Requires(preun): info
+...
+%post
+/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
+%preun
+if [ $1 = 0 ] ; then
+/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
+fi
+There is one other glitch related to installing info manuals.
+The install-info command will update the info directory,
+so we should delete the useless empty directory from the %{buildroot} during the %install section:
+rm -f %{buildroot}%{_infodir}/dir
+Another scriptlet-like abilility are "triggers",
+which can be run for your package when other packages are installed or uninstalled.
+See RPM Triggers.
+Macros
+Macros are text in the format %{string}. Typical macros:
+</code>
+^ Macro	^ Typical Expansion ^ Meaning ^
+| %{_bindir} | /usr/bin | Binary directory: where executables are usually stored. |
+| %{_builddir} | ~/rpmbuild/BUILD | Build directory: files are compiled within a subdirectory of the build directory. See %buildsubdir. |
+| %{buildroot} | ~/rpmbuild/BUILDROOT | Build root: where files are "installed" during the %install stage, which copies files from a subdirectory of %{_builddir} to a subdirectory of %{buildroot}. (Historically, %{buildroot} was in "/var/tmp/".) |
+| %{buildsubdir} | %{_builddir}/%{name} | Build subdirectory: a subdirectory within %{_builddir} where files are compiled during the %build stage. It is set after %setup. |
+| %{_datadir} | /usr/share | Share directory. |
+| %{_defaultdocdir} | /usr/share/doc | Default documentation directory. |
+| %{dist} | .fcNUMBER | Distribution+version short name (e.g. ".fc9") |
+| %{fedora} | NUMBER | Number of fedora release (e.g. "9") |
+| %{_includedir} | /usr/include |  |
+| %{_infodir} | /usr/share/info |  |
+| %{_initrddir} | /etc/rc.d/init.d |  |
+| %{_libdir} | /usr/lib |  |
+| %{_libexecdir} | /usr/libexec |  |
+| %{_localstatedir} | /var |  |
+| %{_mandir} | /usr/share/man |  |
+| %{name} |  | Name of package, set by Name: tag |
+| %{_sbindir} | /usr/sbin |  |
+| %{_sharedstatedir} | /var/lib |  |
+| %{_sysconfdir} | /etc |  |
+| %{version} |  | Version of package, set by Version: tag |
+<code text>
+Learn more about macros by looking in /etc/rpm/* and /usr/lib/rpm, especially /usr/lib/rpm/macros.
+Also use rpm --showrc to show values that RPM will use for macros (altered by rpmrc and macro configuration files).
+You can set your own macro values using %global,
+but be sure to define them before you use them.
+(Macro definitions can also refer to other macros.) For example:
+%global date 2012-02-08
+Use the "-E" option of rpmbuild to find the value of a macro in a SPEC file:
+rpmbuild -E '%{_bindir}' myfile.spec
+Also see Packaging/RPMMacros and RPM Guide chapter 9.
+</code>
+==== Custom Built RPM ====
+[[http://rpm.k2patel.in|my repository]]