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.
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.
Sorry, let me clarify. I like the ".d" layout for letting a group of files
form a valid configuration for a program as well as the override path. i.e.,
read the system wide default, then local host settings, then per user
settings. This is a nice way to structure configuration data.
What I was wanting to say is that users and developers should still regard
these files as config files and should be ok editing them to at least figure
out what they should be set to in order to work. I say this because I don't
want "config file settings should be changed" to be reported as a bug in the
program when it could be a pull request to update the configuration file. If
we're regarding config files as immutable, then there's no reason to have
them.
So, change the config file around, see what makes it work, then send a pull
request to update it in whatever package delivered it.
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.
Entirely reasonable. I can restructure things to work this way and allow host
and user overrides. However, for the latter I think per-project might be more
useful than host overrides since this is the sort of program that doesn't get
value from per-user settings. It's really per project settings. So I would
say:
/usr/share/rpminspect
/etc/rpminspect
.
Where . is the dist-git repo you're working on.
I have /etc/rpminspect/rpminspect.conf now. Suggestions on how I should split
that out and name directories?
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
