RFE: Allow to specify architectures #27
Comments
|
This is a really good idea. Where should I get a list of valid architectures? Since rpminspect is tied to rpm and that universe, should I ask rpm or otherwise look at what it calls an architecture? Should I allow any string and just match every package it iterates through and skip the ones that do not match? That would probably be expensive because it would need to download all packages anyway and that can be avoided. |
|
How do you ask Koji for the download links? Maybe it has some kind of options for this already? |
|
Found it. I can call getAllArches() on the Koji hub and get a list of supported architecture names. I can then validate the command line input from the user and abort if the user gives me an invalid architecture name. Working on the patch. |
This is part 1 of a 2 part enhancement. This commit adds code that
processes a new command line argument called -a or --arches. You
specify a list of architectures you want to run rpminspect for,
delimited by commas. The default mode of operation is to operate on all
found architectures, but there may be instances where you want to
restrict the run to one or a subset of architectures.
The syntax is:
rpminspect -a ARCH,ARCH,ARCH BEFORE_BUILD AFTER_BUILD
There is no "-a ALL" option since the default is to operate on
everything. Architecture names are checked against what the Koji hub
says it can build for. In Fedora right now, a valid -a option would
look like this:
rpminspect -a x86_64,aarch64,ppc64le
If you specify the -a option, the SRPM is not automatically included.
You need to add 'src' to the list. Like this:
rpminspect -a x86_64,aarch64,ppc64le,src
If you specify something like this in Fedora now:
rpminspect -a hppa,mips,sparc64,src
You will get an error telling you hppa is an unsupported architecture.
rpminspect will terminate on the first invalid architecture specified.
The next commit will hook up the build gathering to the architecture
list.
For local and downloaded builds, if the user specifies an architecture list with -a or --arches then only RPMs for those architectures specified are downloaded. Source RPMs are called 'src' in this context.
|
Done. See the commits linked in this issue. Basically you do this: rpminspect -a x86_64,s390x,src To restrict it to those architectures. Works for downloaded builds and local builds, however the architecture list is validated against what the Koji hub supports. |
…inspect#27) This is part 1 of a 2 part enhancement. This commit adds code that processes a new command line argument called -a or --arches. You specify a list of architectures you want to run rpminspect for, delimited by commas. The default mode of operation is to operate on all found architectures, but there may be instances where you want to restrict the run to one or a subset of architectures. The syntax is: rpminspect -a ARCH,ARCH,ARCH BEFORE_BUILD AFTER_BUILD There is no "-a ALL" option since the default is to operate on everything. Architecture names are checked against what the Koji hub says it can build for. In Fedora right now, a valid -a option would look like this: rpminspect -a x86_64,aarch64,ppc64le If you specify the -a option, the SRPM is not automatically included. You need to add 'src' to the list. Like this: rpminspect -a x86_64,aarch64,ppc64le,src If you specify something like this in Fedora now: rpminspect -a hppa,mips,sparc64,src You will get an error telling you hppa is an unsupported architecture. rpminspect will terminate on the first invalid architecture specified. The next commit will hook up the build gathering to the architecture list.
…t#27) For local and downloaded builds, if the user specifies an architecture list with -a or --arches then only RPMs for those architectures specified are downloaded. Source RPMs are called 'src' in this context.
For quick debugging and for integration with Fedora CI pipeline, it would be nice if I could say for example: "I only care about x86_64,noarch,src", to prevent downloading and unpacking extra unwanted packages (~320 MiB for python3).
The text was updated successfully, but these errors were encountered: