About configuration files for the user session

[Steve Langasek]

On Thu, Dec 06, 2012 at 10:42:04AM +0000, Dmitrijs Ledkovs wrote:
> 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.

There are several differences that I think make these less than compelling
precedents.

 - /etc/init was specified before .overrides were supported.
 - autostart files don't support the .override concept at all, AFAIK.  You
   may be able to mask a .desktop file later in the path with the same name,
   but you can't subclass them.
 - system job definitions need to go on the root filesystem for obvious
   reasons, and the FHS has long been mute on the question of whether it's
   ok for software to have subdirectories under /lib (and there is no
   /share), which I believe may have influenced the decision to use
   /etc/init.  The rootfs argument doesn't apply for user jobs.

So I think we should be considering whether it makes sense in its own right
to have a directory in /usr/share too.

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

Well, moving udev rules to /lib was done for much the same reason as what
I'm arguing for here:  over time, having packages dropping rules in
/etc/udev became unmaintainable due to upgrades / local modifications.
Also, the fact that these files persisted when packages were removed (but
not purged).  I think I have a few systems where I'm still dealing with the
after-effects of that particular issue.

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

Yes, I think the best behavior from a usability POV is to not use the
.override in the lower-priority location.  I realize that makes the
implementation more complex, so I wouldn't consider it a blocker.

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

Right; my sense is that as a deprecated path, it should be last among the
list of user-modifiable directories.

-- 
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/20121206/b25bf44a/attachment.pgp>