Name
The Name tag contains the proper name of the package. Names must not include whitespace and may include a hyphen '-' (unlike version and release tags). Names should not include any numeric operators ('<', '>','=') as future versions of rpm may need to reserve characters other than '-'.
By default subpackages are named by prepending `<main package>-' to the subpackages name(s). If you wish to change the name of a subpackage (most commonly this is to change the '-' to '.'), then you must specify the full name with the -n argument in the package definition:
%package -n newname
Description: Screen drawing library Name: screenlib Version: 1.0 %package devel Description: Screen drawing library headers and static libs
might be changed to:
Summary: Screen drawing library Name: screenlib Version: 1.0 %description The screen drawing library is a handy development tool %package devel Summary: Screen drawing library headers and static libs %description devel This package contains all of the headers and the static libraries for screenlib. You'll only need this package if you are doing development.
The description is free form text, but there are two things to note. The first regards reformatting. Lines that begin with white space are considered "pre-formatted" and will be left alone. Adjacent lines without leading whitespace are considered a single paragraph and may be subject to formatting by glint or another RPM tool.
The config(missingok) indicates that the file need not exist on the installed machine. The config(missingok) is frequently used for files like /etc/rc.d/rc2.d/S55named where the (non-)existence of the symlink is part of the configuration in post, and the file may need to be removed when this package is removed. This file is not required to exist at either install or uninstall time.
The config(noreplace) indicates that the file in the package should be installed with extension .rpmnew if there is already a modified file with the same name on the installed machine.
The virtual file attribute token verify tells `-V/--verify' to ignore certain features on files which may be modified by (say) a postinstall script so that false problems are not displayed during package verification.
%verify(not size filedigest mtime) %{prefix}/bin/javaswarm
/tmp/are\.you\|bob\? /tmp/bob\'s\*htdocs\* "/tmp/bob\'s htdocs"
Names containing "%%" will be rpm macro expanded into "%". When trying to escape large number of file names, it is often best to create a file with the complete list of escaped file names. This is easiest to do with a shell script like this:
rm -f $RPM_BUILD_DIR/filelist.rpm echo '%defattr(-,root,root)' >> $RPM_BUILD_DIR/filelist.rpm find $RPM_BUILD_ROOT/%{_prefix} -type f -print | \ sed "s!$RPM_BUILD_ROOT!!" | perl -pe 's/([?|*.\'"])/\\$1/g' \ >> $RPM_BUILD_DIR/filelist.rpm %files -f filelist.rpm
Autoreq: 0
in your spec file. Any and all requirements should be added manually using the
Requires: depend1, ..., dependN
in this case.
Similarly there is an Autoprov tag to turn off the automatic provision generation and a Autoreqprov to turn off both the automatic provides and the automatic requires generation.
The original intent of this ability of RPM was to allow proprietary or non-distributable software to be built using RPM, but to keep the proprietary or non-distributable parts out of the resulting source RPM package, so that they would not get distributed.
They also have utility if you are building RPM packages for software which is archived at a well-known location and does not require that you distribute the source with the binary, for example, for an organization's internal use, where storing large quantities of source is not as meaningful.
The end result of all this, though, is that you can't rebuild ``no-source'' RPM packages using `rpm --rebuild' unless you also have the sources or patches which are not included in the .nosrc.rpm.
1) they are prefixed with build (e.g. BuildRequires: rather than Requires:) 2) they are resolved before building rather than before installing.
So, if you were to write a specfile for a package that requires egcs to build, you would add
BuildRequires: egcs
If your package was like dump and could not be built w/o a specific version of the libraries to access an ext2 file system, you could express this as
BuildRequires: e2fsprofs-devel = 1.17-1
Finally, if your package used C++ and could not be built with gcc-2.7.2.1, you can express this as
BuildConflicts: gcc <= 2.7.2.1