1RPMINSPECT(1) Red Hat RPMINSPECT(1)
3
7 rpminspect - compare package builds
8
10 rpminspect -c FILE [ OPTIONS ] before_build [ after_build ]
11
13 rpminspect is a tool designed to help developers maintain build policy
14 compliance and consistency among releases. The tool has two primary
15 modes of operation. The first is what can be considered an analysis
16 mode. This runs against a single RPM or Koji build (a build being a
17 source RPM and all of its built packages for multiple architectures).
18 The analysis mode checks for package consistency and compliance. Vari‐
19 ous inspections can be configured via the configuration file, profile
20 in use, or local rpminspect.yaml file. The other mode is build compar‐
21 ison. This mode performs all of the same inspections as analysis mode
22 as well as comparisons between a before and after package or build.
23 There is no explicit option to run rpminspect in either mode; the mode
24 of operation is determined by specifying either one or two inputs. One
25 input means analysis mode, two inputs means comparison mode.
26 rpminspect originated at Red Hat as an auditing tool used to ensure
28 builds complied with certain release rules and policies. Over time it
29 grew to incorporate other checks, such as making sure debugging symbols
30 are accurate and various security policies were followed. Users are
31 encouraged to contribute tests for new functionality as well as bug
32 fixes.
33 The software is made available as this command line program and an ac‐
35 companying library. This is intentional. Our findings over time have
36 shown that simple tools with a flexible design are more easy to inte‐
37 grate in to continuous integration systems. The library allows devel‐
38 opment of other frontends should anyone ever be interested in doing
39 that. The thought is that most developers will interact with rpmin‐
40 spect through the command line. Everything about an rpminspect run is
41 configurable at runtime through command line options as well as a con‐
42 figuration file. The command line options override the configuration
43 file which overrides the compiled in defaults.
44
46 -c FILE, --config=FILE
47 Configuration file. This is the only required option. The con‐
48 figuration file is generally provided by a product vendor in the
49 form of /usr/share/rpminspect/VENDOR.yaml. Wrapper scripts are
50 common to prevent the need to specify the configuration file on
51 the command line (e.g., rpminspect-fedora runs rpminspect with
52 the fedora.yaml configuration file).
53 -p NAME, --profile=NAME
55 Optional configuration profile to use. A configuration profile
56 provides overrides to the main configuration file. The idea is
57 the main configuration is loaded, then if you specify a profile
58 name rpminspect will load that configuration file and any values
59 specified will override what came from the default configuration
60 file. Think of the main configuration file as the common one
61 and profile configuration files are optional overlays. Profiles
62 must be in the 'profiledir' directory and follow the naming
63 scheme of PROFILE.yaml. It is common for vendors to provide a
64 set of profiles in addition to a main configuration file.
65 The format of a profile configuration file is the same as the
67 configuration file, just call it NAME.yaml and place it in the
68 'profiledir' for the appropriate vendor. For example, the pro‐
69 file 'scl' for Fedora should have a configuration file named
70 /usr/share/rpminspect/profiles/fedora/scl.yaml.
71 -T LIST, --tests=LIST
73 If specified, this option assumes all inspections are disabled
74 except the names of the ones you specify with this option.
75 Specify a comma-separated list of inspections to run (default:
76 ALL). The names of available inspections can be found with the
77 -l option. You can also specify the name ALL to explicitly say
78 run all inspections. NOTE: This option is mutually exclusive
79 with the -E option.
80 -E LIST, --exclude=LIST
82 If specified, this option assumes all inspections are enabled
83 except the names of the ones you specify with this option.
84 Specify a comma-separated list of inspections to skip (default:
85 none). The names of available inspections can be found with the
86 -l option. You can also specify the name ALL to explicitly say
87 skip all inspections, though that makes the program do nothing.
88 NOTE: This option is mutually exclusive with the -T option.
89 -a LIST, --arches=LIST
91 Comma-separated list of architectures to inspect packages on.
92 By default rpminspect will gather all available architectures
93 for the builds you specify, but you may want to restrict a run
94 to just x86_64 or just aarch64. You can do that with this op‐
95 tion. If you do specify this option, be sure to include the
96 'src' architecture to inspect source packages and 'noarch' to
97 include noarch packages. The architectures you list here are
98 validated against the available architectures in the Koji hub
99 and any invalid ones will report an error.
100 For the purposes of RPM packaging, both 'noarch' and 'src' are
102 considered architectures. Please keep that in mind when using
103 this option.
104 -r STR, --release=STR
106 String identifying the product release for the specified build
107 or builds. Normally rpminspect will determine this by looking
108 for a "dist tag" at the end of the NVR. For build comparisons,
109 the determined product releases must match in order for rpmin‐
110 spect to continue. If you want to compare builds from different
111 products, you will need to specify a product release manually.
112 You will also need to specify the product release if the builds
113 you are comparing lack any kind of product release identifier at
114 the end of the NVR.
115 rpminspect can be configured to favor the newest or oldest prod‐
117 uct release string in case they do not match. This may be use‐
118 ful when comparing builds from one product release to another.
119 -n, --no-rebase
121 Disable rebased build detection. When comparing two builds or
122 two packages, rpminspect will look at the package names, version
123 numbers, and release numbers. If the names and versions match
124 but the releases vary, the package is not considered a rebase
125 because the assumption is this is a maintenance type build on an
126 existing package. Non-rebase comparisons enforce more strict
127 rules for certain inspections. If the package names match but
128 the version numbers differ, rpminspect considers the comparison
129 to be between rebased builds. Rebased comparisons relax those
130 strict rules in order to eliminate a lot of false positives in
131 the output. If you want to always disable the rebase checking
132 and enforce the strict rules, you can pass this option.
133 -o FILE, --output=FILE
135 Write the results to the name output file. By default, results
136 go to stdout.
137 -F TYPE, --format=TYPE
139 Write the inspection results in the TYPE format. The default
140 format is text. Available formats can be seen with the -l op‐
141 tion
142 -t TAG, --threshold=TAG
144 Result threshold that triggers a non-zero exit code. By default
145 this is VERIFY, which maps to a result code seen in the output.
146 You can set this to any of the valid result codes. Available
147 result codes are OK, INFO, WAIVED, VERIFY, or BAD. The argument
148 expects the result threshold specified as a string. Case does
149 not matter.
150 -l, --list
152 List available output formats and inspections
153 -w PATH, --workdir=PATH
155 Temporary working directory to use (default: /var/tmp/rpmin‐
156 spect). You can specify a tilde (~) character in the PATH spec‐
157 ification and rpminspect will expand it. Keep in mind that the
158 PATH you specify with ~ must exist in order for expansion to
159 work.
160 -f, --fetch-only
162 Only download files in specified builds, do not perform any in‐
163 spections (implies -k). This option is intended as a conve‐
164 nience for developers as well as for easier integration in to
165 different CI workflows. Note that this option does not change
166 the working directory (-w) to the current working directory. If
167 this is undesirable, use the -w option to set it to a different
168 location. For example, to download to the current working di‐
169 rectory you can pass "-w $(pwd)".
170 You may specify one or more builds when using the fetch only mode.
172 -k, --keep
174 Do not remove temporary working files before exit. Useful at
175 times for debugging.
176 -d, --debug
178 Enable debugging mode. This mode generates additional output on
179 stdout and stderr.
180 -D, --dump-config
182 Dump configuration settings in use in YAML format. The output
183 of this option will be the combined settings after reading the
184 configuration file, any profile specified, and any local config‐
185 uration file. Useful for debugging to ensure settings have been
186 read in correctly.
187 -v, --verbose
189 Verbose inspection output. By default, only warnings or fail‐
190 ures are reported. This option also displays informational
191 findings. Use this mode with -l to display long descriptions of
192 output formats and inspections.
193 -?, --help
195 Display usage information.
196 -V, --version
198 Display version information.
199
201 rpminspect requires very little to run. Assuming you meet the runtime
202 requirements to either build the software from source or you have in‐
203 stalled it on your operating system, you are ready to use it. The only
204 required arguments are the '-c' option to specify the configuration
205 file and at least one input. The input may be an RPM package (local or
206 remote), a Koji build (either local or remote), or a Koji scratch build
207 task ID. When provided with a single input, rpminspect runs in analy‐
208 sis mode. When two inputs are provided, it performs all of the analy‐
209 sis checks as well as comparison checks.
210 Use the -l option to list available inspections (add -v to get detailed
212 descriptions of the inspections). By default, all inspections will be
213 run. You can restrict the program to a subset of inspections by list‐
214 ing their short names and separating them with commas (no spaces). Or
215 you can list inspections to skip by listing the short name prefixed
216 with a `!' in the same comma-delimited list.
217 Builds may be local RPM packages, regular Koji builds specified using
219 Koji syntax (the NVR or name, version, and release of a package with
220 hyphens separating each part), Koji module builds, locally cached Koji
221 builds (regular or module), Koji scratch builds (task ID number), or
222 locally cached Koji scratch builds. Any valid Koji build identifier
223 works when specifying Koji builds, such as the build ID number or the
224 package NVR. The only exception to this rule is scratch builds. You
225 must use the Koji task ID number for scratch builds. For more informa‐
226 tion on Koji build specification, please see the Koji documentation.
227 If you specify a directory tree containing the output of a properly
229 structured Koji build, rpminspect can use that directly. This may be
230 useful for multiple runs of rpminspect against a specific previous
231 build where you are trying to fix something in a new build compared
232 against the old one.
233 Local RPM packages may be specified directly too if you just want to
235 use rpminspect on a single RPM. You may specify a single RPM package
236 or two if you want rpminspect to perform the comparison inspections.
237 Examples:
239 rpminspect -T ALL -k zlib-1.2.7-1.fc29 zlib-1.2.7-2.fc29
241 rpminspect -T license,elfsyms perl-5.28.0-47.fc6
243 perl-5.28.1-1.fc6
244 rpminspect -T !manpage x3270-3.6ga5-6.fc31 x3270-3.6ga6-1.fc31
246 rpminspect -T ALL -a ppc64le zsh-5.7.1-3.fc31 zsh-5.7.1-4.fc31
248 rpminspect -E disttag -a ppc64le zsh-5.7.1-3.fc31
250 zsh-5.7.1-4.fc31
251 The end result of running rpminspect is a report on standard output ex‐
253 plaining what was found. Descriptions of actions developers can take
254 are provided in the findings.
255
257 rpminspect exits 0 if all inspections pass, 1 if at least one inspec‐
258 tion did not pass, or 2 if a program error occurred.
259
261 Please report bugs at https://github.com/rpminspect/rpminspect using
262 the Issues tab.
263
265 rpm(8)
266
268 David Cantrell <dcantrell@redhat.com>
269rpminspect February 2019 RPMINSPECT(1)