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. (*) (*) Does rpminspect have access to dist-git contents when run in gating? 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
