Upstart helpers (abstract jobs and event aliases) for Oneiric

[James Hunt]

On 07/06/11 18:58, Kees Cook wrote:
> Hi James,
> 
> On Tue, Jun 07, 2011 at 03:00:03PM +0100, James Hunt wrote:
>> == Proposal 2: Provide Abstract Jobs for Common Services ==
>> [...]
>> ==== Option 1 ====
>> [...]
>> For example, each display manager package would be updated such that its
>> .conf file specified:
>>
>>   env    DISPLAY_MANAGER=y
>>   export DISPLAY_MANAGER
>>
>> Then, any job that requires a display manager could say:
>>
>>   start on starting DISPLAY_MANAGER=y
>> [...]
>> ==== Option 2 ====
>> Create a Job Configuration File that hard-codes the list of known
>> service providers. For example for "display-manger", we could have:
>>
>>   start on (starting gdm
>>         or (starting kdm
>>         or (starting lightdm
>>         or (starting lxdm
>>         or (starting slim
>>         or (starting wdm
>>         or  starting xdm))))))
>>
>>   stop on (stopping gdm
>>         or (stopping kdm
>>         or (stopping lightdm
>>         or (stopping lxdm
>>         or (stopping slim
>>         or (stopping wdm
>>         or  stopping xdm))))))
>>
>>   env    ABSTRACT_JOB=y
>>   export ABSTRACT_JOB
>> [...]
>>
>> - We appear to have simply "moved the problem" since although we are no
>>   longer hard-coding the list of display managers in "plymouth.conf", we
>>   are hard-coding the list now in "display-manager.conf". However, we
>>   have gained by doing this since:
>>
>>   - We have still created the level of abstraction desired.
>>   - We have contained the problem into a single file: we define the list
>>     of display managers *once*.
>>   - We don't need to update every Ubuntu (and potentially every Debian)
>>     package as would be required for "Option 1".
>>   - We *could* conceivably auto-generate "display-manager.conf" from the
>>     archive with a simple script which munged the output of:
>>
>>     apt-cache search x-display-manager|awk '{print $1}'|sort
>>
>> - The "ABSTRACT_JOB" variable would allow other jobs to detect that a
>>   job was abstract (they shouldn't need to care, but just in case...)
>>   This also avoids the unwieldliness of "abstract-display-manager" (or
>>   even "abstract/display-manager" (were we to put the abstract jobs in
>>   /etc/init/abstract/ say).
> 
> What about merging the two options? I think it's a mistake to have
> hardcoded lists; this is like having /etc/service.conf instead of
> /etc/service.d/ for things to easily insert themselves into the system.
> 
> Imagine, instead:
> 
>    start on (starting DISPLAY_MANAGER=y
>          or (starting gdm
>          or (starting kdm
>          or (starting lightdm
>          or (starting lxdm
>          or (starting slim
>          or (starting wdm
>          or  starting xdm)))))))
> 
> Then anything not in the hardcoded list can just define itself as a
> DISPLAY_MANAGER to be included, and everything else can still start on the
> abstract job names too.
Great idea! This makes a lot of sense of we go the "kiss" route rather than adopting a new stanza
(such as "alias" as suggested by Marc Dahlhaus).

> 
> -Kees
>