[systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths
Lennart Poettering
lennart at poettering.net
Mon Oct 20 10:50:30 PDT 2014
On Fri, 17.10.14 09:14, Josh Triplett (josh at joshtriplett.org) wrote:
> On Fri, Oct 17, 2014 at 08:40:48AM +0300, Mantas Mikulėnas wrote:
> > On Fri, Oct 17, 2014 at 7:29 AM, Josh Triplett <josh at joshtriplett.org> wrote:
> > > This makes it possible to drop in logind configuration snippets from a
> > > package or other configuration management mechanism.
> >
> > I'm still very curious what packages would need to install drop-ins for logind?
>
> Configuration packages, metapackages, configuration management systems,
> etc.
>
> > > Introduce a new helper, conf_parse_many, to parse configuration files in
> > > a search path.
> > >
> > > systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
> > > rather than /etc/systemd/logind.conf . Distributions should migrate
> > > existing modified versions of /etc/systemd/logind.conf to
> > > /etc/systemd/logind.conf.d/50-default.conf .
> >
> > Sounds like unnecessary shuffling things around...
>
> It's the same process previously followed for /etc/modules moving to
> /etc/modules-load.d, for instance.
Well, you have a point there, but I think there's a difference
here. In files like /etc/modules-load.d/ and /etc/sysctl.d/ every
single line has an equivalent meaning, they just list mostly identical
objects, and if the lines are missing the overall list is simply
shorter, and in its default completely empty. This is different for
configuration files like logind.conf where lines have clear semantics,
and where each individual config line has a different default. The
defaults are non-trivial and can and should be shipped in a primary
logind.conf file, in their full extent. The .d/ drop-ins then just
override or extend them. But if the drop-ins don't exist the options
still are valid, are set, though simply to a specific default. Because
of this I think that it makes sense to keep logind.conf in place by
default, and treat .d/ as extensions, while for /etc/modules-load.d/
and /etc/sysctl.d/ the .d snippets are the primary source of
configuration.
Hope that makes some sense?
> > > For systemd, are "git format-patch -M" patches (with git-style renames
> > > rather than whole-file deletion/insertions) acceptable for mailing list
> > > review? That format makes renames much easier to review.
> >
> > I'm sure the patches are applied using `git am`, so that should work fine.
>
> That was my hope as well.
Correct, I just care about "git am".
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list