On Mon, Mar 16, 2020 at 02:04:53PM -0400, David Cantrell wrote: > On Mon, Mar 09, 2020 at 05:45:34PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Mar 09, 2020 at 10:35:03AM -0700, Adam Williamson wrote: > >>On Mon, 2020-03-09 at 11:49 -0400, David Cantrell wrote: > >>> > >>> > > /etc/rpminspect/rpminspect.conf > >>> > > >>> > So that is a global config file... > >>> > RFE: move it under /usr, and only look for overrides in /etc. > >>> > 99% of users should not modify that, and it shouldn't be in /etc. > >>> > >>> I disagree. Users are allowed to edit configuration files in /etc. > >> > >>True, but Zbigniew isn't wrong either. I think the more modern config > >>pattern he refers to clearly *is* superior; it's much better for the > >>standard configuration to be in a 'not-meant-to-be-edited' file in > >>/usr/share but for the config loading mechanism to look for override > >>snippets in /etc/rpminspect/conf.d or whatever. > > > >Yes, very much so. The important part is to be able to drop-in > >overrides without caring about the rest of the configuration, and to > >have the rest of the configuration update itself on package upgrades > >without me having to do anything. > > > >>It means the upstream configuration can be updated without local > >>customizations being lost, and it's much nicer for the sysadmin as > >>well, for two reasons: > >> > >>1) If you want to have two different local customizations for different > >>purposes, you can put them in 01-this.conf and 02-that.conf , with the > >>names being descriptive. This is *far* easier to understand when you > >>come back to it in three years than a single monolithic config file > >>which you *maybe* wrote some comments in. > >> > >>2) You don't have to read or care about the entire config, your snippet > >>only needs to have as much in it as you actually want to change. > >> > >>> As for the location, I could put it with the rest of the vendor-specific data > >>> in /usr/share/rpminspect and allow for the location in /etc to override it as > >>> you suggest. So it would become: > >>> > >>> /usr/share/rpminspect/rpminspect.conf (if it exists) > >>> /etc/rpminspect/rpminspect.conf (if it exists) > >>> > >>> As stated above, I have a pending patch set that will add .rpminspectrc as the > >>> last one in this list. That would be read from the directory you invoke > >>> rpminspect in. The intent here is to allow package maintainers to add it to > >>> dist-git for further control of how rpminspect runs in gating. > >>> > >>> Then if you specify a profile, it would search dirs in this order: > >>> > >>> /usr/share/rpminspect/profiles > >>> /etc/rpminspect/profiles > >>> > >>> The vendor data package would stop providing the /etc files. I'm not opposed > >>> to this layout. Is this along the lines of what you're thinking? > >> > >>Yeah, except with the snippet thing too. Accept partial config > >>snippets, not just an entire file. > > > >They main way I imagine myself using rpminspect is to have a bunch of > >overrides per package, and some "global" Fedora overrides, and to > >call rpminspect either during review or for koji builds or when > >modifying dist-git. In general I expect the per-package config to live > >in dist-git. ".rpminspect" is OK, but a non-hidden file would be even > >better. (*) > > This makes sense. My reply to adamw mentioned an ordering I was thinking of: > > /usr/share/rpminspect > /etc/rpminspect > . > > Where . is the dist-git project. I was going to go with .rpminspectrc, but I > can name it anything. Do you have any preferences? Not really, the proposal above sounds good. > >(*) Does rpminspect have access to dist-git contents when run in gating? > > Right now it does not, but that is planned pending the config file > restructuring I'm talking about. Sounds good too. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
