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 -s TAG, --suppress=TAG
152 Results suppression threshold. By default all results are re‐
153 ported, but you can use this option to suppress results below a
154 reporting level. The values are the same as for the -t option
155 above. For example, to only show VERIFY and higher results,
156 pass "-s VERIFY" at run time. This option is not valid on the
157 "json" or "xunit" output formats.
158 -l, --list
160 List available output formats and inspections
161 -w PATH, --workdir=PATH
163 Temporary working directory to use (default: /var/tmp/rpmin‐
164 spect). You can specify a tilde (~) character in the PATH spec‐
165 ification and rpminspect will expand it. Keep in mind that the
166 PATH you specify with ~ must exist in order for expansion to
167 work.
168 -f, --fetch-only
170 Only download files in specified builds, do not perform any in‐
171 spections (implies -k). This option is intended as a conve‐
172 nience for developers as well as for easier integration in to
173 different CI workflows. Note that this option does not change
174 the working directory (-w) to the current working directory. If
175 this is undesirable, use the -w option to set it to a different
176 location. For example, to download to the current working di‐
177 rectory you can pass "-w $(pwd)".
178 You may specify one or more builds when using the fetch only mode.
180 -k, --keep
182 Do not remove temporary working files before exit. Useful at
183 times for debugging.
184 -d, --debug
186 Enable debugging mode. This mode generates additional output on
187 stdout and stderr.
188 -D, --dump-config
190 Dump configuration settings in use in YAML format. The output
191 of this option will be the combined settings after reading the
192 configuration file, any profile specified, and any local config‐
193 uration file. Useful for debugging to ensure settings have been
194 read in correctly.
195 -v, --verbose
197 Verbose inspection output. By default, only warnings or fail‐
198 ures are reported. This option also displays informational
199 findings. Use this mode with -l to display long descriptions of
200 output formats and inspections.
201 -?, --help
203 Display usage information.
204 -V, --version
206 Display version information.
207
209 rpminspect requires very little to run. Assuming you meet the runtime
210 requirements to either build the software from source or you have in‐
211 stalled it on your operating system, you are ready to use it. The only
212 required arguments are the '-c' option to specify the configuration
213 file and at least one input. The input may be an RPM package (local or
214 remote), a Koji build (either local or remote), or a Koji scratch build
215 task ID. When provided with a single input, rpminspect runs in analy‐
216 sis mode. When two inputs are provided, it performs all of the analy‐
217 sis checks as well as comparison checks.
218 Use the -l option to list available inspections (add -v to get detailed
220 descriptions of the inspections). By default, all inspections will be
221 run. You can restrict the program to a subset of inspections by list‐
222 ing their short names and separating them with commas (no spaces). Or
223 you can list inspections to skip by listing the short name prefixed
224 with a `!' in the same comma-delimited list.
225 Builds may be local RPM packages, regular Koji builds specified using
227 Koji syntax (the NVR or name, version, and release of a package with
228 hyphens separating each part), Koji module builds, locally cached Koji
229 builds (regular or module), Koji scratch builds (task ID number), or
230 locally cached Koji scratch builds. Any valid Koji build identifier
231 works when specifying Koji builds, such as the build ID number or the
232 package NVR. The only exception to this rule is scratch builds. You
233 must use the Koji task ID number for scratch builds. For more informa‐
234 tion on Koji build specification, please see the Koji documentation.
235 If you specify a directory tree containing the output of a properly
237 structured Koji build, rpminspect can use that directly. This may be
238 useful for multiple runs of rpminspect against a specific previous
239 build where you are trying to fix something in a new build compared
240 against the old one.
241 Local RPM packages may be specified directly too if you just want to
243 use rpminspect on a single RPM. You may specify a single RPM package
244 or two if you want rpminspect to perform the comparison inspections.
245 Examples:
247 rpminspect -T ALL -k zlib-1.2.7-1.fc29 zlib-1.2.7-2.fc29
249 rpminspect -T license,elfsyms perl-5.28.0-47.fc6
251 perl-5.28.1-1.fc6
252 rpminspect -T !manpage x3270-3.6ga5-6.fc31 x3270-3.6ga6-1.fc31
254 rpminspect -T ALL -a ppc64le zsh-5.7.1-3.fc31 zsh-5.7.1-4.fc31
256 rpminspect -E disttag -a ppc64le zsh-5.7.1-3.fc31
258 zsh-5.7.1-4.fc31
259 The end result of running rpminspect is a report on standard output ex‐
261 plaining what was found. Descriptions of actions developers can take
262 are provided in the findings.
263
265 rpminspect exits 0 if all inspections pass, 1 if at least one inspec‐
266 tion did not pass. rpminspect exits 3 if the specified profile is not
267 found, and 2 if any other program error occurred.
268
270 Please report bugs at https://github.com/rpminspect/rpminspect using
271 the Issues tab.
272
274 rpm(8)
275
277 David Cantrell <dcantrell@redhat.com>
278rpminspect February 2019 RPMINSPECT(1)