About configuration files for the user session

[Dmitrijs Ledkovs]

On 5 December 2012 20:26, Steve Langasek <steve.langasek at ubuntu.com> wrote:
> On Wed, Dec 05, 2012 at 10:50:45AM +0000, Dmitrijs Ledkovs wrote:
>> 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:
>
>> > 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.
>
> This does mean there's no way for a package to provide a template user job
> that is not itself considered a configuration file (with all the resulting
> requirements for the package to manage it as such).
>

Yes. Which is already the case /etc/xdg/autostart/*.desktop files and
for all the /etc/init*/* files.
Hmm... I don't know the history of /etc/udev/rules.d =>
/lib/udev/rules.d move, but it would be nice to avoid a similar path
transitions.

>> > 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.
>
> I understand that concern, but I find that it violates my own intuition
> about how this should work.  Yes, having multiple locations to look for a
> .conf or .override is confusing, but OTOH it's also confusing to copy
> /etc/xdg/upstart/foo.conf to ~/.config/upstart/foo.conf if all you actually
> want to do is add an override (perhaps to set the job "manual"),
> particularly if you later drop the .override and then don't understand why
> you're no longer getting the upstream behavior (thanks to the shadow copy).
>
> Despite the implementation complexity, my suggested handling allows a couple
> of simple rules for users to follow:
>
>  - override the behavior of a default upstart user job (including disabling
>    it): ~/.config/upstart/foo.override
>  - create your own job: ~/.config/upstart/foo.conf
>  - restore the default system behavior for a job: rm
>    ~/.config/upstart/foo.override
>  - change the packaged job behavior for all users on your system as part of
>    a site policy: /etc/xdg/xdg/upstart/foo.override
>
> Both approaches certainly provide many remaining opportunities for
> foot-shooting, but I think my suggestion makes it easier to express to users
> how to do things the *right* way.
>

Ok. I like that: use the first found conf & the first found override.


>> 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 ?
>
> I think /home/user2/.config/upstart/foo.override should mask
> /etc/xdg/upstart/foo.override, causing /etc/xdg/upstart/foo.override to not
> be read.
>

Ok. What about this case:

/etc/xdg/upstart/foo.conf
/etc/xdg/upstart/foo.override
/home/user1/.config/foo.conf

Is the override file used or not? I.e. do we look at the overrides in
the lower priority locations than the conf file itself or not?

First conf file wins + first override wins which is in the same
directory as the conf file or earlier in the search path.

>> 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.
>
> Right - but I think "first one wins" works fine here just as it does for the
> .conf itself, so you should only apply the .override in the user's homedir.
>

Ack.

> (BTW, I just noticed that ~/.init was listed as a higher priority than
> ~/.config/upstart, despite the statement that ~/.init is deprecated.  If
> it's deprecated, wouldn't we want it last?)
>

"Currently, PID 1 looks for a users Job configuration files in
directory $HOME/.init/. This behaviour will be retained." [1]

This statement is ambiguous, I interpreted it as ~/.init is highest
priority - to preserve running existing user jobs which may or may not
break with new user-session events.

So I am not sure where in the search path ~/.init should be, as per
above intention.

[1] https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs

--
Regards,
Dmitrijs.