About configuration files for the user session

[Steve Langasek]

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).

> > 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.

> 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.

> 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.

(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?)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121205/113a68e9/attachment.pgp>