Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 438494 - Have configuration file protection against new files in conf.d/ directories
Summary: Have configuration file protection against new files in conf.d/ directories
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-15 18:03 UTC by Jack Eids_no_google_me_ness
Modified: 2012-10-16 15:46 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Eids_no_google_me_ness 2012-10-15 18:03:39 UTC
The majority of server programs with config files in /etc/ are protected by portage from overwriting custom configurations, because the new file is created initially as a dot-file, and is detected by programs such as dispatch-conf. This is so work is not lost. There is an additional benefit, though, and this may be an unintended side effect, but the configs are usually protected from being changed to a broken configuration, through the same mechanism.

However, If a program, such as apache or dovecot gets a new file in a conf.d/ directory where the program has a wildcard match on config files, the new file is just entered into the mix with the rest, regardless of how it may interact with the existing configuration files, and regardless of any dependencies between content in new and changed config files - changes to existing files which have not been saved to the real config file. So it doesn't always enjoy the same benefit of a non-broken configuration.

Could it be possible for a package to establish a wildcard pattern similar to what these conf.d directories match on, so that portage can use that to create new files as dot-files that do not match the pattern?

e.g. on the upgrade to dovecot 2.1, instead of creating /etc/dovecot/conf.d/15-mail.conf as a new config file, create /etc/dovecot/conf.d/._cfg0000_15-mail.conf?

This should only be relevant to an upgrade or the initial install of these programs would be broken, or perhaps, if any file is detected, the others could be written as dot files for dispatch-conf to integrate.
Comment 1 Zac Medico gentoo-dev 2012-10-16 00:24:12 UTC
(In reply to comment #0)
> Could it be possible for a package to establish a wildcard pattern similar
> to what these conf.d directories match on, so that portage can use that to
> create new files as dot-files that do not match the pattern?

You want the package to configure this for you automatically, by installing a configuration file containing patterns for the package manager to use?

> This should only be relevant to an upgrade or the initial install of these
> programs would be broken, or perhaps, if any file is detected, the others
> could be written as dot files for dispatch-conf to integrate.

For the initial install, the mentioned "configuration file containing patterns" would not be installed yet, so maybe that would be enough to prevent it from breaking the initial install.
Comment 2 Jack Eids_no_google_me_ness 2012-10-16 15:41:22 UTC
Well, I don't really know a lot technically about how ebuilds, dispatch-conf, etc-update and all of the interrelated apps work, and the more my suggestion leans into implementation details, the less likely my input will be useful. That being said, I think what you said sounds good.

At my level, as a gentoo admin and someone who has written & compiled software but never written an ebuild or explored the portage code, I guess I was thinking it would be some kind of magic that could come out of a new ebuild option, and I might not ever know exactly how it figured it out.

I thought of another hitch, by the way, which is that I'm not actually positive that dovecot or apache's wildcard will not match dot-files, assuming they end with ".conf"
Comment 3 Zac Medico gentoo-dev 2012-10-16 15:46:11 UTC
If this is something that ebuilds will need to be aware of, then it should go in PMS.