About configuration files for the user session

[Dmitrijs Ledkovs]

On 7 December 2012 01:04, Steve Langasek <steve.langasek at ubuntu.com> wrote:
> On Thu, Dec 06, 2012 at 04:39:00PM +0000, James Hunt wrote:
>> I've attempted to distill what is becoming a rather difficult-to-follow
>> discussion due to all the examples in the spec here:
>
>> https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Collision_Resolution
>
>> Please update if you spot problems.
>
> The table here is very confusing to me with its references to "system
> files".  Is this /etc/init, or /etc/xdg/upstart?  Given the distinction
> drawn between system and user files, I would have assumed it's /etc/init,
> but your terminology table suggests it's /etc/xdg/upstart.
>

The table is highly detailed and draws arbitrary distinction between
search paths.
We will have a list a conf-sources of arbitrary length.
And we simply need to prioritise within that search path loading of
.conf & .override files.
This should not be any more complex than finding an executable like in $PATH.

>> Note that I've also updated the Terminology section and special-cased
>> "System Directories and Files" such that they should be considered as
>> "higher priority" than User Directories to allow sysadmins to control user
>> jobs via overrides to some extent, as already discussed in this thread.
>
> I think that's exactly the opposite of what is being proposed in this
> thread.  It's the user's file that should take precedence over the system
> copy, not vice-versa.
>

To make this clear by default packages install job files into
/etc/xdg/upstart/ [*]
Such that by default all users execute and launch them.
Then system administrator decides that by default gwibber should not
be launched,
so system-administrator drops an /etc/xdg/upstart/gwibber.override.
But I as a user decide that I launch gwibber application everytime
anyway, so I drop a ~/.config/upstart/gwibber.override to launch it
anyway.
Some time later, system administrator thinks that nobody should ever
be using gwibber and purges gwibber package from the system.

[*] for now assume we don't have a location in /usr/share/

>> I totally agree that we want to avoid user confusion. Therefore, I think
>> that along with strong documentation, we should update init-checkconf(8)
>> to run something like 'init --user --list-jobs' which will not run a
>> Session Init, but which will print:
>
>> - each directory it is searching.
>> - each file it finds.
>> - whether the file will be considered or not based on either implicit XDG
>> paths, or --confdir ones.
>
>> Thus allowing a user/admin to make sense of what is happening.
>
> Sounds like a reasonable debugging aid.  I think it would be readable to
> only report on the files that are actually used, though, and ignore those
> that are being masked out.
>
>> I agree that ~/.init should be considered last. _Please_ feel free to
>> update the spec if you notice problems - it's a working document for all
>> to contribute to :-).
>
> I don't currently see the proposed search path specified anywhere in this
> document.  Should this be under
> https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs
> ?
>

I have now updated & simplified that part of the spec.

>> Steve - I'm not clear on whether you're suggesting we need to consider
>> perhaps a "/usr/share/upstart/conf/" too (a la initramfs-tools in Ubuntu?)
>
> Yes, I am proposing that.
>

What should it be though? (bikeshed colour alert)

/usr/share/upstart/
/usr/share/upstart/conf/
/usr/share/upstart/session/
/usr/share/upstart/user/

>> Regarding allowing multiple --confdir invocations on the command-line, I
>> really would prefer we have this - it's just exposing the internal search
>> path logic, shouldn't be difficult to implement and would be invaluable
>> for (non-DEP-8) testing in my view.
>
> That means there would be two *different* mechanisms for specifying a series
> of config dirs, with different semantics: one by adjusting the contents of
> $XDG_CONFIG_DIRS, the other by passing multiple --confdir options.  I think
> this is more flexibility than we really want to have to manage.
>

I was on and off about this. There is no need to multiple --confdir
options, since for unit-tests one can simply add additional
conf_sources via API. If one is actually executing the binary, there
are plenty of environment variables one can adjust (HOME,
XDG_CONFIG_HOME, XDG_CONFIG_DIRS).

Regards,

Dmitrijs.