[systemd-devel] Standardizing names for graphical session units

[Jóhann B. Guðmundsson]

>
>> ># gnome-user-graphical.target
>> >
>> >[Unit]
>> >Description=User systemd services for graphical session
>> >StopWhenUnneeded=yes
> So this is just another name for "my"
> gnome.target/gnome-session.target. As I said I'm not too fussed about
> how we name those, we should just decide about some convention.

Right.

>
>> >In your script you had an conflicting naming scheme (
>> >gnome.target/graphical.target ) and a colliding one ( graphical.target with
>> >systemd default and potentially other DE's as well ) if multiple desktop
>> >environments where installed.
> I don't see a conflict. These are all per-user units, so if user A
> runs kde-session.target and user B runs gnome-session.target that's
> fine -- the two user systemd instances don't even know about each
> other.

It's more about people will be have hard time distinguish between two or 
more type units with the same name but serve two different purposes.

This would work if an new type unit would be introduced which could be 
called .session or .user so you would end up with gnome.session or 
gnome.user instead of gnome.target for example or gnome.service etc.

It might be an option to introduce a new type unit(s) since the existing 
type units might not be the right way to handle this.

>> >And you also might need to add something like an Alias ( like for example
>> >"Alias=user-graphical.target" ) directive to the DE-user-graphical.target
>> >unit so that someapp.service can be made PartOf an generic directive
>> >(PartOf=user-graphical.target) to make it DE agnostic ( should it be
>> >required to be so ) if it's not DE specific. ( if you follow me here ).
> I do follow. However, there is no such thing as a "runtime alias" for
> units, TTBOMK. There is Alias= in the [Install] section, but this
> cannot really be used for this purpose -- we don't want to change
> the /usr/lib/systemd/user/user-graphical.target symlink every time
> that we start a user session in a DM.

I was just using it as an example since you have the same problem trying 
to describe "generic" ordering/requirement/dependency in type units.

One way to solve them is with type target units as you proposed ( 
user-graphical.target could serve that purpose ) but back in the day 
Lennart was against introducing generic type targets like 
webserver.target, database.target etc which would have simplified things 
quite a bit in various type service for applications that needed for 
example be ordered either after or before like After=webserver.target vs 
having to define all of them in the existence 
Apache,Nginx,Lighttpd,Monkey,Cherokee,Hiawatha etc. So I just 
automatically dismissed that as a solution since I assumed he would be 
consistent and reject such proposals/ideas.

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160706/444695ff/attachment.html>