We seriously recommend you consider configuration files for products you are going to have to build more then once, or for seriously complex products that make use of Revisor functions beyond what is a simple click-and-go exercise, such as rebranding and other advanced customization. On the other hand, if you are just to try one or two simple things just for this once, command-line options might be more suitable.
Revisor uses configuration files for a large part of it's operations. These files mostly reside in /etc/revisor/. There is two types of configuration files Revisor uses:
Revisor configuration files, such as /etc/revisor/revisor.conf, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose.
YUM configuration files, such as the files in /etc/revisor/conf.d/, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in /etc/revisor/conf.d/ practically contain the same information as /etc/yum.conf combined with the files in /etc/yum.repos.d/ (but not exactly the same content!).
4.1.1. /etc/revisor/revisor.conf
The default Revisor configuration file is /etc/revisor/revisor.conf. This configuration file contains two sections:
The global section. Options specified in this section apply to all the models defined in this configuration file.
Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings.
Using models, you can reproduce the outcome of the compose process, a product, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently.
To see what models are available with the Revisor standard package, use:
4.1.2. /etc/revisor/conf.d/
The default YUM configuration files used by Revisor. In a model configuration section, the main = setting points to one of the YUM configuration files in /etc/revisor/conf.d/.
The YUM configuration files configure the repositories available during a product compose, as well as the available architectures.
4.1.3. Updates to Configuration Files
The Revisor packages (or any packages in Fedora for that matter) are not allowed to overwrite existing configuration files in /etc/, and they should thus not do so. Users anticipate that if they change a file in /etc/ these changes are persistent in that they are not destroyed when a package is updated. If an update to Revisor is installed on your system, files with the extension .rpmnew may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by searching for and examining the .rpmnew files.
You can use any file location (not just /etc/revisor/) for your own custom configuration.
4.1.4. Changing Configuration Files
If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then /etc/revisor/revisor.conf, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes.
