It would be great to have drop-in configuration directory, like /etc/mf2b.d/ and include *.conf files from it. It will be unconvient to update /etc/mf2b.conf from /etc/mf2b.conf.rpmnew (or alike) after package update.
First of all, thanks for your feedback. I somehow assumed it would take longer
until someone discovers my new project. :)
The requested config directory is in line with logrotate's config system,
implemented as 'include' directive of the main one. In that case, it is a
convenient way to allow third-party packages to install/maintain a logrotate
file for their own log(s). Sometimes, one finds a /etc/logrotate.d despite
logrotate not being installed at all.
In the case of mf2b, I don't think this pattern applies equally well: the
config's information is quite system- or even administrator-dependant, so it
should be hard for a package maintainer to guess how it's mf2b-config should
look like (despite maybe the regex to act upon).
I am not sure what you mean with that package update scenario you describe -
isn't that always the case? Unless you're not populating /etc/mf2b.d with
example configs, the user would have to merge them after an update as well.
For package maintainers, I would recommend to either not install a
/etc/mf2b.conf in the first place, or live with the user having to merge it.
The problem of merging updated configurations is not the software project's
problem, but rather the distribution's one.
You could still get away without any limitations: install a
/etc/mf2b.conf.sample with lots of heavily commented configuration samples,
hinting the user to create /etc/mf2b.conf from it. You should be able to
update it without hassle, if the user edits the sample config he deserves to
merge anyway. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thanks for your feedback. I somehow assumed it would take longer
until someone discovers my new project. :)
The requested config directory is in line with logrotate's config system,
implemented as 'include' directive of the main one. In that case, it is a
convenient way to allow third-party packages to install/maintain a logrotate
file for their own log(s). Sometimes, one finds a /etc/logrotate.d despite
logrotate not being installed at all.
In the case of mf2b, I don't think this pattern applies equally well: the
config's information is quite system- or even administrator-dependant, so it
should be hard for a package maintainer to guess how it's mf2b-config should
look like (despite maybe the regex to act upon).
I am not sure what you mean with that package update scenario you describe -
isn't that always the case? Unless you're not populating /etc/mf2b.d with
example configs, the user would have to merge them after an update as well.
For package maintainers, I would recommend to either not install a
/etc/mf2b.conf in the first place, or live with the user having to merge it.
The problem of merging updated configurations is not the software project's
problem, but rather the distribution's one.
You could still get away without any limitations: install a
/etc/mf2b.conf.sample with lots of heavily commented configuration samples,
hinting the user to create /etc/mf2b.conf from it. You should be able to
update it without hassle, if the user edits the sample config he deserves to
merge anyway. :)