autospec - Create an RPM package spec file automatically
autospec [ -bdhimwzL ] [ -c copyright ] [ -g group ] [ -l
language_list ] [ -n name-version ] [ -r rpm-version ]
autospec creates spec files used by the Red Hat Package
Manager rpm(8) in building RPM packages. It uses the
information it can determine to fill in the proper spec
file fields. If it cannot determine a required item, it
makes an educated guess or inserts a commented-out field
as a guide to the user. This allows a human packager to
use the generated spec file as an almost complete template
to quickly create an RPM package from a typical source
archive. The spec files generated use features available
in rpm version 3.0, but can optionally generate spec files
compatible with earlier versions (as early as 2.4)
By default, autospec expects a list of absolute file names
on its standard input to use as the contents of the RPM
package. If the -i command-line option is used, then
autospec expects a list of the commands used to install
the program on the system. These commands, including
those like cp(1) and install(1) that are typically exe
cuted by running `make install', are parsed to extract the
names of the files being installed. The -i option does a
better job if the program is already installed on the
The following install commands are recognized and parsed
for file names: chgrp, chmod, chown, cp, ginstall,
install, ln, mkdir, touch. The following install commands
are ignored: bison, byacc, bzip2, cc, cd, compress, echo,
flex, gcc, g++, gzip, ld, lex, ranlib, rm, strip, yacc.
Any remaining commands cause a warning message to be
If -w is used, then the log file generated by install
watch(1) is expected in standard input instead. install
watch is available as part of the checkinstall(1) package,
available from <URL:http://asic-linux.com.mx/~izto/check
Whether the file names come from a list or an install
script, the file types are inferred from the file names
with hints from file status information in the local
filesystem. This results in a list of files and file
types in the %files section of the spec file. If errors
are encountered while parsing the install script, then
appropriate warning messages are written to the standard
The -n option can override the RPM name which is normally
based on the current directory name. If the name looks
like it has a version number embedded, that is used as the
RPM version number.
When -b is specified, the default parameters to some spec
options are set properly for binary source archives. These
are assumed to contain files already in the proper direc
tory locations in the archive, and are designed to be
installed simply by un-tarring them from the root direc
If a Linux Software Map (.lsm) file exists in the current
directory and the -m option is not given, information is
extracted from it to fill in the spec file. Fields that
can be filled in this way are Version, Copyright, Summary,
Source, and %description. The contents of several of
these can be overridden at creation time by other command-
Older versions of rpm do not support some of the spec file
constructs that autospec can place into the spec files it
generates. If you would like spec files that can be used
with older versions of rpm to create packages, you can use
the -r option to specify the version with which you would
like to have compatibility. Currently, only the values
2.4, 2.5 and 3.0 are supported and values outside this set
are rounded to the closest value.
autospec will give good results for the majority of pro
grams. However, programs with complex installation scripts
will often produce many warnings when used with autospec's
-i option, and the resultant spec file may contain invalid
or missing files in the %files section. The spec file will
need to be manually edited to fix such problems. Using
installwatch and the -w option while installing these pro
grams will give a more complete spec file.
There is no way for autospec to know with certainty the
correct contents of the %prep, %build and %install sec
tions of the spec file, so it inserts the most common com
mands. These must always be manually checked and changed
Following is how a user could use autospec to create a
spec file for the source archive `foo-1.23.tar.gz'.
1) Un-tar the archive into a suitable directory (e.g. tar
2) Change to that directory and run `make' to create the
program, then `make install' to install it on the system
3) Run autospec to create a spec file (e.g. make -n
install | autospec -i > foo.spec)
4) Edit the foo.spec file, adding appropriate Group and
Copyright fields, if necessary, and making any other
5) Create an RPM package with the spec file (e.g. rpmbuild
If there is no `install' target in the make file (or there
is no make file) then the command in step 3 can be
replaced by something like `/bin/ls -d /usr/local/bin/foo
/usr/local/lib/foo/* | autospec > foo.spec'
If autospec gives too many warning messages in step 3 and
it misses too many files, then you may wish to install the
installwatch(1) package and use it to track which files
are installed. In this case, replace step 3 with a com
mand like `installwatch -o install.log make install;
autospec -w < install.log > foo.spec'
If the source file needs to be patched, then a diff must
be generated from the original source files and the spec
file modified to use it in the build process. The details
are beyond the scope of this document.
autospec also handles binary tar balls where the files are
stored in their proper places in the directory hierarchy.
A sample directory of such a tar.gz file might look like:
The following command creates a fully-functional spec file
for such an archive:
tar tzf foo-1.23-bin.tar.gz | autospec -bd -c GPL -g Util
ities/System -n foo-1.23 -l '' > foo.spec
-b Source archive is a binary archive, ready to be un-
tarred directly into the local filesystem. -d
should be specified whenever this option is chosen.
Specifies the contents of the Copyright: or
License: line in the spec file. If not specified
and an LSM file is found, its contents are used.
If no LSM file is available and the -m option has
not been given, likely files in the current direc
appropriate Copyright: line is generated if one is
found. Otherwise, the line is commented out and
must be edited by hand before the spec file can be
-d Don't look at most files in the current directory.
This includes looking for documentation files like
`README' and `BUGS', looking for a configure
script, and looking for contents for the %descrip
tion section and Copyright: or License: lines, but
does not include looking for an .lsm file (see -m).
Specifies the contents of the Group: line in the
spec file. If not specified, the Group: line is
determined by looking at the file list and making
an educated guess. The guess is tailored to the OS
distribution installed on the local machine (which
is determined by looking at /etc/*-release files).
Often, no guess is likely to be correct and instead
the Group: line is commented out and must be edited
by hand before the spec file can be used. A list of
recommended groups can be found in the file
/usr/doc/rpm-N/groups or /usr/share/doc/rpm-
N/GROUPS where N depends on the version of rpm you
-h Show brief command help.
-i Standard input is assumed to contain a program
installation shell script instead of a list of
Additional language-specific Summary:, Group: and
%description entries are added to the spec file,
but commented out, for each language specified.
These extra entries should be manually edited
before the spec file is used. language_list should
consist of RFC 1766 language codes (usually the
two-letter codes from ISO 639), separated by com
mas. The language of the current locale is used as
the default argument, if it's not English (this
doesn't work on old Python versions). Use an empty
argument of '' to suppress the default. Multilin
gual entries are not generated when creating spec
files for RPM version 2.4.
-m Don't use the contents of a Linux Software Map file
ending in .lsm if found in the current directory to
fill in more of the spec file. Don't look for text
files with software license details in the current
RPM name with optional embedded version number. By
default, the RPM name is the current directory
Generate spec files compatible with the given ver
sion of rpm (defaults to 3.0).
-w Standard input is assumed to contain the output of
installwatch instead of a list of files.
-z Indicate that the source archive is in ZIP format
instead of gzipped tar format.
-L Display software license
autospec's exit status is 0 on success, 1 when given a bad
command-line option, and 2 when errors are encountered
while parsing the input file names.
default location of autospec program
The command tokenizing done with the -i option is quite
crude as it doesn't take into account escape characters,
redirection or most other special characters. Not all
options of the recognized commands are accepted. Complex
installation scripts using environment variables, `for'
loops, `if' statements or other shell commands will pro
duce warnings and may cause missing or incorrect files in
the %files section. The installwatch program offers a good
way to overcome this limitation as it directly tracks
function calls commonly used by installation programs.
Software built with the GNU autoconf(1) system is not han
dled very well. Use the -w option and installwatch on
If someone else has already packaged your program into an
RPM, it's often better to install the .src.rpm and start
from that spec file instead of using autospec. This is
especially true for larger, more complex packages that
autospec doesn't always handle very well. See
<URL:http://www.rpmfind.net> to see if an RPM is already
available for your package.
Daniel Fandrich <email@example.com>
Thanks to Christian Thayer, Marc Lavallée and Scott Dudley
for bug reports.
autospec is copyright © 1997-2003 by Daniel Fandrich. It
is provided "as is", without any express or implied war
ranties. See the file COPYING for details.
Man(1) output converted with