1RPMINSPECT(1) Red Hat RPMINSPECT(1)
3
7 rpminspect - compare package builds
8
10 rpminspect [ 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 is intended to
15 provide output alerting the developer to any changes in the built pack‐
16 ages that significantly differ from a previous built; the implication
17 being the previous build has already been made available to users.
18 rpminspect originated at Red Hat as an auditing tool used by the QA
20 department to ensure builds complied with certain release rules and
21 policies. Over time it grew to incorporate other checks, such as mak‐
22 ing sure debugging symbols are accurate. Users are encourage to con‐
23 tribute tests for new functionality as well as bug fixes.
24 The software is made available as this command line program and an
26 accompanying library. This is intentional. Our findings over time
27 have shown that simple tools with a flexible design are more easy to
28 integrate in to continuous integration systems. The library allows
29 development of other frontends should anyone ever be interested in
30 that. The thought is that most developers will interact with rpmin‐
31 spect through the command line. Everything about an rpminspect run is
32 configurable at runtime through command line options as well as a con‐
33 figuration file. The command line options override the configuration
34 file which overrides the compiled in defaults.
35
37 -c FILE, --config=FILE
38 Configuration file to use (default: /etc/rpminspect/rpmin‐
39 spect.conf)
40 -r STR, --release=STR
42 String identifying the product release for the specified build
43 or builds. Normally rpminspect will determine this by looking
44 for a "dist tag" at the end of the NVR. For build comparisons,
45 the determined product releases must match in order for rpmin‐
46 spect to continue. If you want to compare builds from different
47 products, you will need to specify a product release manually.
48 You will also need to specify the product release if the builds
49 you are comparing lack any kind of product release identifier at
50 the end of the NVR.
51 -T LIST, --tests=LIST
53 If specified, this option assumes all inspections are disabled
54 except the names of the ones you specify with this option.
55 Specify a comma-separated list of inspections to run (default:
56 ALL). The names of available inspections can be found with the
57 -l option. You can also specify the name ALL to explicitly say
58 run all inspections. NOTE: This option is mutually exclusive
59 with the -E option.
60 -E LIST, --exclude=LIST
62 If specified, this option assumes all inspections are enabled
63 except the names of the ones you specify with this option.
64 Specify a comma-separated list of inspections to skip (default:
65 none). The names of available inspections can be found with the
66 -l option. You can also specify the name ALL to explicitly say
67 skip all inspections, though that makes the program do nothing.
68 NOTE: This option is mutually exclusive with the -T option.
69 -l, --list
71 List available output formats and inspections
72 -a LIST, --arches=LIST
74 Comma-separated list of architectures to inspect packages on.
75 By default rpminspect will gather all available architectures
76 for the builds you specify, but you may want to restrict a run
77 to just x86_64 or just aarch64. You can do that with this
78 option. If you do specify this option, be sure to include the
79 'src' architecture to inspect source packages. The architec‐
80 tures you list here are validated against the available archi‐
81 tectures in the Koji hub and any invalid ones will report an
82 error.
83 -o FILE, --output=FILE
85 Write the results to the name output file. By default, results
86 go to stdout.
87 -F TYPE, --format=TYPE
89 Write the inspection results in the TYPE format. The default
90 format is text. Available formats can be seen with the -l
91 option.
92 -w PATH, --workdir=PATH
94 Temporary working directory to use (default: /var/tmp/rpmin‐
95 spect). You can specify a tilde (~) character in the PATH spec‐
96 ification and rpminspect will expand it. Keep in mind that the
97 PATH you specify with ~ must exist in order for expansion to
98 work.
99 -f, --fetch-only
101 Only download builds, do not perform any inspections (implies
102 -k). This option is intended as a convenience for developers as
103 well as for easier integration in to different CI workflows.
104 -k, --keep
106 Do not remove temporary working files before exit
107 -v, --verbose
109 Verbose inspection output. By default, only warnings or fail‐
110 ures are reported. This option also displays informational
111 findings.
112 -?, --help
114 Display usage information
115 -V, --version
117 Display version information
118
120 rpminspect requires very little to run. Assuming you meet the runtime
121 requirements to either build the software from source or you have
122 installed it on your operating system, you are ready to use it. The
123 only required argument is a build, which we will call the before_build.
124 It is possible to run rpminspect against a single build and perform the
125 policy checks against the packages in it. If two builds are specified,
126 the policy checks are performed, but the builds are also compared.
127 Use the -l option to list available inspections. By default, all
129 inspections will be run. You can restrict the program to a subset of
130 inspections by listing their short names and separating them with com‐
131 mas (no spaces). Or you can list inspections to skip by listing the
132 short name prefixed with a `!' in the same comma-delimited list.
133 Builds are specified using koji syntax. The common method is the NVR,
135 or name, version, and release of a package with hyphens separating each
136 part. But you can also supply any valid koji build identifier. For
137 example, you can use the koji build ID number. For more information on
138 koji build specification, please see the koji documentation.
139 Lastly, builds may be local to the system you are using. If you spec‐
141 ify a directory tree containing the output of a properly structure koji
142 build, rpminspect can use that directly. This may be useful for multi‐
143 ple runs of rpminspect against a specific previous build where you are
144 trying to fix something in a new build compared against the old one.
145 Examples:
147 rpminspect -T ALL -k zlib-1.2.7-1.fc29 zlib-1.2.7-2.fc29
149 rpminspect -T license,elfsyms perl-5.28.0-47.fc6
151 perl-5.28.1-1.fc6
152 rpminspect -T !manpage x3270-3.6ga5-6.fc31 x3270-3.6ga6-1.fc31
154 rpminspect -T ALL -a ppc64le zsh-5.7.1-3.fc31 zsh-5.7.1-4.fc31
156 rpminspect -E disttag -a ppc64le zsh-5.7.1-3.fc31
158 zsh-5.7.1-4.fc31
159 The end result of running rpminspect is a report on standard output
161 explaining what was found. Descriptions of actions developers can take
162 are provided in the findings.
163
165 rpm(8)
166
168 David Cantrell <dcantrell@redhat.com>
169rpminspect February 2019 RPMINSPECT(1)