New profiles spec

[Alex Smith]

Scott James Remnant wrote:
> On Fri, 2007-06-01 at 07:19 +0100, Alex Smith wrote:
> 
>> I wrote a new draft of the Profiles spec from some discussion on IRC. 
>> I'd like to know of any improvements and/or problems you can think of 
>> for it. Over this weekend I'll try to implement it in my own branch.
>>
>> The spec is here: http://upstart.ubuntu.com/wiki/Profiles
>>
> Some comments:
> 
> The config file syntax isn't very Upstartish...  Perhaps something a bit
> more like:
> 
>  /etc/init/profiles.d/no-x:
>    enable *
>    disable gdm
>    disable kdm
>    disable xdm
>    disable ldm
> 
> Rather than the ini-ish syntax?  Remember that " " and "=" are valid
> characters in a job name <g>
> 
> This would be easier to program since you could just use nih/config to
> parse it with an "enable" or "disable" stanza.

Right, that's better. I originally thought of the syntax I wrote in the 
spec because I've already written a parser for that syntax before so I 
could reuse the code ;)

> Any particular reason why we need "bootprofile=" on the kernel
> command-line.  Since the arguments are passed to Upstart directly
> anyway, we could use the names of profiles directly:
> 
>   root=/dev/hda1 quiet splash no-x no-network
> 
> (And then we can even have "quiet" and "splash" profiles for free <g>)

Hmm, that'd probably be better, too :)

> 
> 
> What set of profiles would be the "default"?  If everything enabled, are
> profiles mostly being used to just disable groups of services?  If the
> default has some things disabled, how do we define what they are, and
> how are they enabled again?

The default would just be to enable everything. My intention with the 
specification was that profiles would simply be used to disable 
services, and allow users to disable different profiles for different 
scenarios (server, no-server, etc). If a distro were to provide a 
package that they don't want to run by default, they could call a 
utility that disables a job in the default profile (maybe the other 
profiles too?)

> 
> Could profiles be groups of services; and thus enabled or disabled?  You
> could define a "networking" profile that has the list of services that
> are networking-related, if the profile is "enabled" then these can be
> run, if it is "disabled" then they cannot be.
> 
> 
> Can only one profile be enabled at a time?  It might be interesting to
> think about profile combinations; since "no-x" and "no-network" are
> quite common suggestions there.  And "recovery" might be a combination
> profile of several things.

I originally thought for only one profile enabled at a time, yes. The 
idea is interesting, but it adds a fair bit of complexity to the 
implementation.
> 
> 
> If just one profile can be enabled at a time, it makes sense for it to
> be just "initctl profile PROFILE" (switch is needless); if multiple can,
> perhaps "initctl enable PROFILE" and "initctl disable PROFILE" ?

Yeah, the switch part of the command was useless, don't know why I put 
that :p

> 
> Scott

Thanks,
Alex
-- 
Alex Smith
Frugalware Linux developer - http://www.frugalware.org