Autospec 0.8 review

autospec creates spec files used by the Red Hat Package Manager rpm(8) in building RPM packages

License: GPL (GNU General Public License) File size: 0K Developer: Dan Fandrich

0

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) instead.

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 local machine.

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 printed.

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 install/ >.

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 directory locations in the archive, and are designed to be installed simply by un-tarring them from the root directory.

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-line options.

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 sections of the spec file, so it inserts the most common commands. These must always be manually checked and changed where necessary.