rpm
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| rpm [2016/08/26 15:58] – [First RPM] 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 Common Command ==== | ||
| + | |||
| + | ^ Syntax ^Description^ | ||
| + | | rpm -ivh {rpm-file} | Install the package | | ||
| + | | rpm -Uvh {rpm-file} | Upgrade package | | ||
| + | | rpm -ev {package} | Erase/ | ||
| + | | rpm -ev --nodeps {package} | Erase/ | ||
| + | | rpm -qa | Display list all installed packages | | ||
| + | | rpm -qi {package} | Display installed information along with package version and short description | | ||
| + | | rpm -qf {/ | ||
| + | | rpm -qc {pacakge-name} | Display list of configuration file(s) for a package | | ||
| + | | rpm -qcf {/ | ||
| + | | 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 ==== | ||
| + | |||
| + | <code bash> | ||
| + | rpm --scripts -qp < | ||
| + | </ | ||
| + | |||
| + | ==== First RPM ==== | ||
| + | |||
| + | Name of Package : libtorrent\\ | ||
| + | Building it in folder "/ | ||
| + | <code bash> | ||
| + | mkdir / | ||
| + | cd / | ||
| + | mkdir BUILD RPMS SOURCES SPECS SRPMS | ||
| + | </ | ||
| + | |||
| + | Creating macro not bad idea. | ||
| + | <code bash | / | ||
| + | %packager Ketan Patel | ||
| + | </ | ||
| + | |||
| + | Get Sources from [[http:// | ||
| + | Place it in "/ | ||
| + | I have used following method. | ||
| + | <code bash> | ||
| + | cd / | ||
| + | svn co svn:// | ||
| + | tar -cvf / | ||
| + | </ | ||
| + | Considering building rtorrent at non standard location. | ||
| + | |||
| + | NOTE : **Please make sure code below has some SUSE Based Customization** | ||
| + | |||
| + | <code bash | / | ||
| + | %define name libtorrent | ||
| + | %define srcdir / | ||
| + | %define _topdir %{srcdir}/ | ||
| + | |||
| + | |||
| + | summary: rTorrent | ||
| + | name: libtorrent | ||
| + | Source: libtorrent.tar.gz | ||
| + | License: GPL | ||
| + | version: 1 | ||
| + | release: 1 | ||
| + | Group: System/ | ||
| + | Prefix: / | ||
| + | buildarch: x86_64 | ||
| + | BuildRoot: %{prefix}/ | ||
| + | %define lib %{prefix}/ | ||
| + | %define include %{prefix}/ | ||
| + | Provides: libtorrent | ||
| + | Requires: ncurses, libcppunit-devel | ||
| + | AutoReqProv: | ||
| + | |||
| + | |||
| + | %description | ||
| + | libtorrent is a BitTorrent client for ncurses, using | ||
| + | the libtorrent library. The client and library is | ||
| + | written in C++ with emphasis on speed and efficiency, while delivering | ||
| + | equivalent features to those found in GUI based clients in an ncurses | ||
| + | client. | ||
| + | |||
| + | %prep | ||
| + | %setup -q -n libtorrent | ||
| + | |||
| + | |||
| + | %build | ||
| + | chmod 755 autogen.sh | ||
| + | ./ | ||
| + | %{suse_update_config -f} | ||
| + | autoreconf -fiv | ||
| + | ./configure --prefix=%{prefix} --libdir=%{lib} | ||
| + | make prefix=$RPM_BUILD_ROOT | ||
| + | |||
| + | %install | ||
| + | rm -rf %{buildroot} | ||
| + | make DESTDIR=$RPM_BUILD_ROOT install | ||
| + | rm -rf $RPM_BUILD_ROOT/ | ||
| + | |||
| + | |||
| + | %clean | ||
| + | make clean | ||
| + | rm -rf %{buildroot} | ||
| + | |||
| + | %files | ||
| + | %defattr(-, | ||
| + | %doc README | ||
| + | / | ||
| + | / | ||
| + | |||
| + | %post | ||
| + | echo "/ | ||
| + | ldconfig | ||
| + | |||
| + | %postun | ||
| + | rm -rf %{prefix} | ||
| + | rm / | ||
| + | ldconfig | ||
| + | |||
| + | %Changelog | ||
| + | * Mon Nov 08 2010 Seriously, Check release son!! | ||
| + | Initial Build | ||
| + | </ | ||
| + | |||
| + | == Building Actual RPM == | ||
| + | <code bash> | ||
| + | cd / | ||
| + | </ | ||
| + | <code bash> | ||
| + | rpmbuild -v -bb --clean SPECS/ | ||
| + | </ | ||
| + | OR | ||
| + | <code bash> | ||
| + | rpmbuild -ba SPECS/ | ||
| + | </ | ||
| + | == Test Your RPM == | ||
| + | <code bash> | ||
| + | rpm -Vp RPMS/ | ||
| + | </ | ||
| + | |||
| + | ==== Something i come across ==== | ||
| + | If you wanna override marco from OS you can define value at '' | ||
| + | <code bash> | ||
| + | %define _mandir /usr/man | ||
| + | </ | ||
| + | ==== Sample RPM ==== | ||
| + | <code bash | sample.spec> | ||
| + | Name: xgauguin-support | ||
| + | Summary: | ||
| + | Version: | ||
| + | Release: | ||
| + | Vendor: | ||
| + | License: | ||
| + | Group: | ||
| + | URL: | ||
| + | BuildRoot: %{_tmppath}/ | ||
| + | BuildArch: noarch | ||
| + | Requires: | ||
| + | |||
| + | %description | ||
| + | Gauguin supporting packages | ||
| + | |||
| + | %install | ||
| + | [ " | ||
| + | %{__mkdir_p} %{buildroot}%{_localstatedir}/ | ||
| + | %{__mkdir_p} %{buildroot}%{_localstatedir}/ | ||
| + | |||
| + | %pretrans | ||
| + | ## Force installation of conflicts | ||
| + | # libxml2.i386, | ||
| + | if $( ! rpm -q libxml2.i386 > /dev/null 2>& | ||
| + | then | ||
| + | | ||
| + | yumdownloader libxml2.i386 > /dev/null 2>&1 | ||
| + | %{__rm} / | ||
| + | rpm --force -ivh libxml2*.rpm | ||
| + | %{__rm} libxml2*.rpm > /dev/null 2>&1 | ||
| + | fi | ||
| + | |||
| + | if $( ! rpm -q perl-Locale-Codes > /dev/null 2>& | ||
| + | then | ||
| + | set -m | ||
| + | yumdownloader perl-Locale-Codes > /dev/null 2>&1 | ||
| + | %{__rm} / | ||
| + | rpm --force -ivh perl-Locale-Codes*.rpm > /dev/null 2>&1 | ||
| + | %{__rm} libxml2*.rpm > /dev/null 2>&1 | ||
| + | fi | ||
| + | |||
| + | %pre | ||
| + | ## Check if vlad user exists, if not add them | ||
| + | if $( ! id vlad >/ | ||
| + | then | ||
| + | | ||
| + | | ||
| + | fi | ||
| + | |||
| + | ##Add user to sudoers | ||
| + | if $( ! grep vlad / | ||
| + | then | ||
| + | echo "vlad ALL=NOPASSWD: | ||
| + | fi | ||
| + | |||
| + | %post | ||
| + | ##Add nginx to startup | ||
| + | chkconfig --level 345 nginx on | ||
| + | |||
| + | ##Create symlink for nginx.conf | ||
| + | if [ ! -h / | ||
| + | then | ||
| + | ln -f -s %{_localstatedir}/ | ||
| + | fi | ||
| + | |||
| + | |||
| + | %files | ||
| + | %defattr(-, | ||
| + | %attr(-, | ||
| + | %attr(777, | ||
| + | |||
| + | %changelog | ||
| + | * Fri May 13 2010 Jason Thomas < | ||
| + | - Initial package creation | ||
| + | </ | ||
| + | |||
| + | === changelog === | ||
| + | You can use following one liner for changelog. | ||
| + | <code bash> | ||
| + | awk ' | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Good Reading ==== | ||
| + | |||
| + | [[http:// | ||
| + | [[http:// | ||
| + | [[http:// | ||
| + | |||
| + | ==== 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 | ||
| + | %preun | ||
| + | %postun | ||
| + | | ||
| + | %triggerun | ||
| + | %triggerpostun | ||
| + | </ | ||
| + | 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 ==== | ||
| + | |||
| + | === List Content === | ||
| + | <code bash> | ||
| + | rpm -qpl file.rpm | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Error on Building ==== | ||
| + | === module: command not found === | ||
| + | Try running following command and then execute rpmbuild will resolve the issue. | ||
| + | <code bash> | ||
| + | source / | ||
| + | </ | ||
| + | ==== MOCK ==== | ||
| + | |||
| + | Mock is a really nice tool to generate RPM cleanly.\\ | ||
| + | I used KVM / MOCK to build RPM for my own reasons but you can use just mock and clean env. after every build.\\ | ||
| + | |||
| + | General Details Available at [[ http:// | ||
| + | |||
| + | Rather then guessing i have pasted all the command i have used to build RPM from srpm.\\ | ||
| + | Using / Generating Spec require another tutorial this is strictly about some work around and keeping env. between transaction. | ||
| + | |||
| + | |||
| + | == Install Mock == | ||
| + | <code bash> | ||
| + | yum install mock | ||
| + | </ | ||
| + | |||
| + | == Add user to group == | ||
| + | I am using rpmbuild user. | ||
| + | <code bash> | ||
| + | usermod -a -G mock rpmbuild | ||
| + | </ | ||
| + | |||
| + | == Initialize Mock == | ||
| + | Before you work on anything Please initialize the environment.\\ | ||
| + | It is good practice to initialize Environment between every build cycle to clean any possible left over or unforeseen issue. | ||
| + | |||
| + | <code bash> | ||
| + | mock --init -r epel-5-x86_64 | ||
| + | </ | ||
| + | |||
| + | === su to user === | ||
| + | You can not run mock as root so .... | ||
| + | <code bash> | ||
| + | su rpmbuild | ||
| + | </ | ||
| + | |||
| + | == Install required packages == | ||
| + | I found that installed package stays installed during cycles.\\ | ||
| + | So you do not require to install packages every time unless you initialize env. | ||
| + | |||
| + | <code bash> | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | == Building SRPM == | ||
| + | <code bash> | ||
| + | mock -r epel-6-x86_64 --spec icinga-web.spec --sources=../ | ||
| + | </ | ||
| + | ==== Copying Files ==== | ||
| + | <note important> | ||
| + | <code bash> | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | |||
| + | == Get SRPM == | ||
| + | <code bash> | ||
| + | cd ~ | ||
| + | wget http:// | ||
| + | </ | ||
| + | |||
| + | == Finally Building RPM == | ||
| + | < | ||
| + | --no-clean : this will keep your files intact in build env.\\ | ||
| + | --no-cleanup-after : i wanted to keep all work file so i used this just incase. | ||
| + | </ | ||
| + | |||
| + | <code bash> | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | In general case result will be stored in '/ | ||
| + | |||
| + | ==== SPEC file Overview ==== | ||
| + | |||
| + | This is mostly from following URL [[http:// | ||
| + | |||
| + | <code text> | ||
| + | |||
| + | Other useful guides: | ||
| + | |||
| + | RPM Guide describes how to write a SPEC file. | ||
| + | The IBM series " | ||
| + | Maximum RPM has the most complete information, | ||
| + | You will need to follow the Fedora guidelines: Package Naming Guidelines, Packaging guidelines, and Package review guidelines. | ||
| + | |||
| + | Insert comments with a leading "#" | ||
| + | If commenting out a line, double the percent signs (%%). Also avoid inline comments on the same line as a script command. | ||
| + | |||
| + | The major tags are listed below. Note that the macros %{name}, %{version} and %{release} can be used to refer to the Name, | ||
| + | Version and Release tags respectively. When you change the tag, the macros automatically update to use the new value. | ||
| + | |||
| + | Name: The (base) name of the package, which should match the SPEC file name. | ||
| + | It must follow the Package Naming Guidelines and generally be lowercase. | ||
| + | Version: The upstream version number. See Version tag section of the packaging guidelines. | ||
| + | If the version contains tags that are non-numeric (contains tags that are not numbers), | ||
| + | you may need to include the additional non-numeric characters in the Release tag. | ||
| + | If upstream uses full dates to distinguish versions, consider using version numbers of the form yy.mm[dd] (e.g. 2008-05-01 becomes 8.05). | ||
| + | |||
| + | Release: The initial value should normally be 1%{? | ||
| + | Increment the number every time you release a new package for the same version of software. | ||
| + | When a new upstream version is released, change the Version tag to match and reset the Release number to 1. | ||
| + | See Release tag section of the packaging guidelines. The optional Dist tag might be useful. | ||
| + | |||
| + | Summary: A brief, one-line summary of the package. Use American English. Do not end in a period. | ||
| + | |||
| + | Group: This needs to be a pre-existing group, like " | ||
| + | run "less / | ||
| + | Use the group " | ||
| + | |||
| + | License: The license, which must be an open source software license. | ||
| + | Do not use the old Copyright tag. Use a standard abbreviation (e.g. " | ||
| + | (e.g. use " | ||
| + | See Licensing and the Licensing Guidelines. | ||
| + | You can list multiple licenses by combining them with " | ||
| + | |||
| + | URL: The full URL for more information about the program (e.g. the project website). | ||
| + | |||
| + | Note: This is not where the original source code came from which is meant for the Source0 tag below. | ||
| + | |||
| + | Source0: The full URL for the compressed archive containing the (original) pristine source code, | ||
| + | as upstream released it. " | ||
| + | If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory. | ||
| + | If possible, embed %{name} and %{version}, so that changes to either will go to the right place. | ||
| + | Preserve timestamps when downloading source files. If there is more than one source, name them Source1, | ||
| + | Source2 and so on. If you're adding whole new files in addition to the pristine sources, | ||
| + | list them as sources after the pristine sources. A copy of each of these sources will be included in any SRPM you create, | ||
| + | unless you specifically direct otherwise. See Source URL for more information on special cases (e.g. revision control). | ||
| + | |||
| + | Patch0: The name of the first patch to apply to the source code. | ||
| + | If you need to patch the files after they' | ||
| + | you should edit the files and save their differences as a " | ||
| + | Patches should make only one logical change each, so it's quite possible to have multiple patch files. | ||
| + | |||
| + | BuildArch: If you're packaging files that are architecture-independent (e.g. shell scripts, data files), | ||
| + | then add " | ||
| + | |||
| + | BuildRoot: This is where files will be " | ||
| + | This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in " | ||
| + | |||
| + | BuildRequires: | ||
| + | This field can be (and is commonly) repeated on multiple lines. These dependencies are not automatically determined, | ||
| + | so you need to include everything needed to build the program. Some common packages can be omitted, such as gcc. | ||
| + | You can specify a minimum version if necessary (e.g. "ocaml >= 3.08" | ||
| + | If you need the file /EGGS, determine the package that owns it by running "rpm -qf / | ||
| + | If you need the program EGGS, determine the package that owns it by running "rpm -qf `which EGGS`" | ||
| + | Keep dependencies to a minimum (e.g. use sed instead of perl if you don't really need perl's abilities), | ||
| + | but beware that some applications permanently disable functions if the associated dependency is not present; | ||
| + | in those cases you may need to include the additional packages. The " | ||
| + | |||
| + | Requires: A comma-separate list of packages that are required when the program is installed. | ||
| + | Note that the BuildRequires tag lists what is required to build the binary RPM, | ||
| + | while the Requires tag lists what is required when installing/ | ||
| + | a package may be in one list or in both. In many cases, | ||
| + | rpmbuild automatically detects dependencies so the Requires tag is not always necessary. | ||
| + | However, you may wish to highlight some specific packages as being required, or they may not be automatically detected. | ||
| + | |||
| + | %description: | ||
| + | Use American English. All lines must be 80 characters or less. | ||
| + | Blank lines indicate a new paragraph. Some graphical user interface installation programs will reformat paragraphs; | ||
| + | lines that start with whitespace will be treated as preformatted text and displayed as is, normally with a fixed-width font. | ||
| + | See RPM Guide. | ||
| + | |||
| + | %prep: Script commands to " | ||
| + | Typically this is just " | ||
| + | See the %prep section below for more. | ||
| + | |||
| + | %build: Script commands to " | ||
| + | The program should come with instructions on how to do this. See the %build section below for more. | ||
| + | |||
| + | %check: Script commands to " | ||
| + | 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 " | ||
| + | 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: | ||
| + | rm -rf %{buildroot} | ||
| + | |||
| + | %files: The list of files that will be installed. See the %files section below for more. | ||
| + | |||
| + | %changelog: Changes in the package. Use the format example above. | ||
| + | |||
| + | ExcludeArch: | ||
| + | list those architectures under this tag. | ||
| + | You can add sections so that code will run when packages are installed or removed on the real system | ||
| + | (as opposed to just running the %install script, which only does a pseudo-install to the build root). | ||
| + | These are called " | ||
| + | See the " | ||
| + | from a single SPEC file, such as name-libs and name-devel packages. | ||
| + | |||
| + | Do not use these tags: | ||
| + | |||
| + | Packager | ||
| + | Vendor | ||
| + | Copyright | ||
| + | Do not create a " | ||
| + | </ | ||
| + | |||
| + | ==== 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 " | ||
| + | (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 " | ||
| + | |||
| + | -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 " | ||
| + | |||
| + | -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 " | ||
| + | Patches are the normal method of making necessary changes to the source code for packaging. | ||
| + | The usual " | ||
| + | |||
| + | Patch file names often look like " | ||
| + | which is the format %{name} - %{version} - REASON.patch" | ||
| + | Patch files are typically the result of "diff -u"; | ||
| + | if you do this from the subdirectory of ~/ | ||
| + | |||
| + | This is a typical procedure for creating a patch for a single file: | ||
| + | |||
| + | cp foo/bar foo/ | ||
| + | vim foo/bar | ||
| + | diff -u foo/ | ||
| + | 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 " | ||
| + | |||
| + | cp -pr ./ ../ | ||
| + | ... many edits ... | ||
| + | diff -u ../ | ||
| + | If you edit many files in one patch, you can also copy the original files | ||
| + | using some consistent ending such as " | ||
| + | Then, you can use " | ||
| + | |||
| + | Try to ensure that your patch match the context exactly. | ||
| + | The default " | ||
| + | You can work around this by adding " | ||
| + | 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/ | ||
| + | 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/ | ||
| + | |||
| + | %prep section: Unmodified files | ||
| + | Sometimes, one or more of the Source files do not need to be uncompressed. | ||
| + | You can " | ||
| + | |||
| + | cp -p %SOURCE1 . | ||
| + | | ||
| + | The " | ||
| + | here you configure and compile/ | ||
| + | |||
| + | Many programs follow the GNU configure approach (or some variation). | ||
| + | By default, they will install to a prefix of "/ | ||
| + | However, since you are packaging it, change the prefix to "/ | ||
| + | Libraries should be installed to either /usr/lib or /usr/lib64 depending on the architecture. | ||
| + | |||
| + | Since GNU configure is so common, the macro " | ||
| + | invoke the correct options (e.g. change the prefix to /usr). Some variation of this often works: | ||
| + | |||
| + | | ||
| + | make %{? | ||
| + | To override makefile variables, pass them as parameters to make: | ||
| + | |||
| + | make %{? | ||
| + | More more information, | ||
| + | | ||
| + | "Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf" | ||
| + | |||
| + | Some programs use cmake. See Packaging/ | ||
| + | |||
| + | | ||
| + | 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 | ||
| + | | ||
| + | This section involves script commands to " | ||
| + | copying the relevant files from %{_builddir} to %{buildroot} | ||
| + | (which usually means from ~/ | ||
| + | and creating directories inside %{buildroot} as necessary. | ||
| + | |||
| + | Some of the terminology can be misleading: | ||
| + | |||
| + | The "build directory", | ||
| + | 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 ~/ | ||
| + | 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" | ||
| + | |||
| + | %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 " | ||
| + | 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 | ||
| + | " | ||
| + | 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: | ||
| + | try to preserve timestamps if the makefile lets you override commands: | ||
| + | |||
| + | make INSTALL=" | ||
| + | |||
| + | | ||
| + | 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. | ||
| + | |||
| + | | ||
| + | The %defattr set the default file permissions, | ||
| + | Note that this is no longer necessary unless the permissions need to be altered. The format of this is: | ||
| + | |||
| + | %defattr(< | ||
| + | The fourth parameter is often omitted. | ||
| + | Usually one uses %defattr(-, | ||
| + | |||
| + | 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: | ||
| + | If the pattern begins with a "/" | ||
| + | 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 / | ||
| + | then the %files section can simply be: | ||
| + | |||
| + | %files | ||
| + | %{_sbindir}/ | ||
| + | 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}/ | ||
| + | Note that %{_bindir}/ | ||
| + | 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. | ||
| + | |||
| + | | ||
| + | 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, " | ||
| + | %{_builddir} that were not copied to %{buildroot}. | ||
| + | A README and INSTALL file is usually included. | ||
| + | They will be placed in the directory / | ||
| + | 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 " | ||
| + | don't use %doc, but instead create the directories and copy files over manually | ||
| + | into %{buildroot}%{_defaultdocdir}/ | ||
| + | They will be correctly marked as documentation. | ||
| + | Make sure you include %{_defaultdocdir}/ | ||
| + | |||
| + | 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}/ | ||
| + | If the update uses a non-backwards-compatible configuration format, then specify them like this: | ||
| + | |||
| + | %config %{_sysconfdir}/ | ||
| + | " | ||
| + | where a " | ||
| + | |||
| + | %attr(0644, root, root) FOO.BAR | ||
| + | If a file is in particular natural language, use %lang to note that: | ||
| + | |||
| + | %lang(de) %{_datadir}/ | ||
| + | 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: | ||
| + | use the found filenames: %files -f ${name}.lang | ||
| + | These prefixes are not valid in Fedora: %license and %readme. | ||
| + | |||
| + | | ||
| + | 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 / | ||
| + | which is referred to as %{_libexecdir}/ | ||
| + | |||
| + | Do not install files into /opt or /usr/local. | ||
| + | |||
| + | Unfortunately, | ||
| + | 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. | ||
| + | |||
| + | | ||
| + | Here's a simple example of a %files section: | ||
| + | |||
| + | %files | ||
| + | %doc README LICENSE | ||
| + | %{_bindir}/ | ||
| + | %{_sbindir}/ | ||
| + | %{_datadir}/ | ||
| + | %config(noreplace) %{_sysconfdir}/ | ||
| + | Finding duplicates | ||
| + | You can list any duplicates of two binary packages by doing: | ||
| + | |||
| + | cd ~/ | ||
| + | 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/ | ||
| + | |||
| + | 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' | ||
| + | If the package has multiple subpackages with libraries, | ||
| + | each subpackage should also perform the same actions. | ||
| + | |||
| + | %post -p / | ||
| + | %postun -p / | ||
| + | If only running a single command, then the " | ||
| + | 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 " | ||
| + | |||
| + | %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): | ||
| + | Requires(preun): | ||
| + | ... | ||
| + | %post | ||
| + | / | ||
| + | %preun | ||
| + | if [ $1 = 0 ] ; then | ||
| + | / | ||
| + | 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}/ | ||
| + | Another scriptlet-like abilility are " | ||
| + | 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: | ||
| + | </ | ||
| + | |||
| + | |||
| + | ^ Macro ^ Typical Expansion ^ Meaning ^ | ||
| + | | %{_bindir} | /usr/bin | Binary directory: where executables are usually stored. | | ||
| + | | %{_builddir} | ~/ | ||
| + | | %{buildroot} | ~/ | ||
| + | | %{buildsubdir} | %{_builddir}/ | ||
| + | | %{_datadir} | /usr/share | Share directory. | | ||
| + | | %{_defaultdocdir} | / | ||
| + | | %{dist} | .fcNUMBER | Distribution+version short name (e.g. " | ||
| + | | %{fedora} | NUMBER | Number of fedora release (e.g. " | ||
| + | | %{_includedir} | / | ||
| + | | %{_infodir} | / | ||
| + | | %{_initrddir} | / | ||
| + | | %{_libdir} | /usr/lib | | | ||
| + | | %{_libexecdir} | / | ||
| + | | %{_localstatedir} | /var | | | ||
| + | | %{_mandir} | / | ||
| + | | %{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 / | ||
| + | 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 " | ||
| + | |||
| + | rpmbuild -E ' | ||
| + | Also see Packaging/ | ||
| + | </ | ||
| + | |||
| + | ==== Custom Built RPM ==== | ||
| + | |||
| + | [[http:// | ||