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?
(*) 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.
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
