On 7 December 2012 01:04, Steve Langasek <[email protected]> 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. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
