[systemd-devel] [PATCH] units: Make getty at .service install rule generic.

Colin Guthrie gmane at colin.guthr.ie
Wed Feb 13 01:29:44 PST 2013


'Twas brillig, and Lennart Poettering at 13/02/13 03:13 did gyre and gimble:
> On Wed, 06.02.13 09:47, Colin Guthrie (colin at mageia.org) wrote:
> 
>> The getty at .service used to specifically enable a getty at tty1.service
>> under getty.target when enabled.
>>
>> Modern versions of systemd allow commands such as:
>>  systemctl enable getty at tty2.service
>> which automatically create the correct symlink if the
>> Install rule permits it.
>>
>> This changes the default getty at .service to follow this
>> now standard convension.
>>
>> Note: Packagers may need to change their initial install
>> rules due to this change (e.g. in rpm %post etc)
> 
> Hmm, but what happens then if people do run
> 
> systemctl enable getty at .service?
> 
> We really need to get the story right on this, I guess, so that
> something useful happens in both cases?

The same could be said of any templated unit with a WantedBy= section I
guess.

One idea off the top of my head is to have a NoInstanceAlias= directive,
but adding a new verb here seems fugly.

Perhaps we could abuse the - syntax?

e.g.:
Alias=-getty.target.wants/getty at tty1.service
WantedBy=getty.target

With - in an Alias meaning

"The Alias to be used when no instance name is given in the
enable/disable commands. If an instance name is supplied the Alias is
ignored and any WantedBy directives are processed."

To be doubly robust, it could be a parse error in any unit that is not a
template.


That might also be considered a little ugly too, but saves on a new
directive and still mostly fits the "silent degradation" meaning of -.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the systemd-devel mailing list