About configuration files for the user session

[Dmitrijs Ledkovs]

On 5 December 2012 05:50, Steve Langasek <steve.langasek at ubuntu.com> wrote:
> On Tue, Dec 04, 2012 at 05:50:29PM +0000, Dmitrijs Ledkovs wrote:
>> Currently in upstart by default the following conf-source locations are used:
>
>> system jobs:
>> /etc/init.conf ( cannot be overridden )
>> /etc/init.d ( can be overridden with UPSTART_CONFDIR, which can be
>> overridden with --confdir )
>> user jobs:
>> ~/.init ( cannot be overridden, not enabled by default in ubuntu )
>
>> With the introduction of upstart managed user sessions the following
>> changes will done:
>
>> system jobs - stay as they are.
>
>> user jobs will have the following priorities (first location wins):
>
>> --confdir dir1 (--confdir dir2) [1]
>> ~/.init (legacy location, deprecated)
>> ${XDG_CONFIG_HOME:~/.config}/upstart ( enabled only if --user is passed )
>> For each dir in ${XDG_CONFIG_DIRS:/etc/xdg} $dir/upstart (enabled only
>> if --user is passed ) [1]
>
> For me, $XDG_CONFIG_DIRS currently points to:
>
>   /etc/xdg/xdg-ubuntu:/etc/xdg
>

(Note ubuntu above is the name of the session / session type)
First is session type specific location, the next one is the default.
Currently on my machine nothing uses the session type location.

> So it seems the proposal includes no directory under /usr for job
> definitions.  Should there be one?
>

I do not believe there should be one. As XDG scheme allows: per
session, per system, per user overrides.

>> Now the .overrides. I'd like to support .override file next to the
>> currently active job file only.
>> For example:
>
>> /etc/xdg/upstart/foo.conf
>> /etc/xdg/upstart/foo.override
>> /home/user1/.config/upstart/foo.conf
>> /home/user2/.config/upstart/foo.override
>> /home/user3/.config/upstart/foo.conf
>> /home/user3/.config/upstart/foo.override
>
>> The following config file will be used in each case:
>> user1: /home/user1/.config/upstart/foo.conf
>> user2: /etc/xdg/upstart/foo.override
>> user3: /home/user3/.config/upstart/foo.override
>> others: /etc/xdg/upstart/foo.override
>
>> The idea is that we use existing XDG style of overriding config files
>> by using user home directory.
>> But we also support upstart override of the job file, if placed in the
>> same confsource directory right next to the currently active job file.
>
>> Does this sound reasonable? I'm trying to cover all corner cases.
>> By default we will only have /etc/xdg/upstart/*.conf jobs and that's it.
>
> The value of .override files is that they allow overriding parts of the job
> without having to modify the original file.  If users have to copy the .conf
> file to their directory before they can override it, that somewhat defeats
> the purpose.  So I think we would want the first override in the path to be
> applied to any matching job file in that directory, *or* in any later
> directory in the path.
>
> What's the argument for (from your example) ignoring
> /home/user2/.config/upstart/foo.override?
>

I do not want to support nested overrides & ordering of those. As that
is confusing.

E.g. if we are to consider /home/user2/.config/upstart/foo.override
will we apply it on top of /etc/xdg/upstart/foo.conf or on top of both
/etc/xdg/upstart/foo.conf+/etc/xdg/upstart/foo.override ?

Currently such an override (without a corresponding conf file) is
considered as orphaned and is ignored. Given the priorities & order of
conf-sources we parse them in first found order (e.g. the first found
foo.conf "wins") and then I am proposing to support only one override
file next to it. If on the other hand we choose to support override
files from other locations, we will then have to walk and apply all
other override files.

I can imagine how-to's on the internet & askubuntu popping up
everywhere suggesting to override the job in this or that place, and I
really do not want to support this case:

/etc/xdg/xdg-ubuntu/upstart/foo.conf
/etc/xdg/xdg-ubuntu/upstart/foo.override
/etc/xdg/xdg/upstart/foo.override
~/.init/foo.override
~/.config/upstart/foo.override

There is like little chance these override files are consistent among
each other and it's hard to edit/override since the context is spread
across many files now.

>> Do we need / want to support specifying multiple --confdir locations
>> on command line? (currently we only look at the last --confdir
>> specified)
>
> I don't see any reason that would be needed.
>

Ack.

Regards,

Dmitrijs.