[systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-06 15:23 +0000]:
> What I'm ( poorly ) trying to say is that you will need to make a clear
> distinction of naming on the type units for the desktop environment and the
> type units for the desktop environment user

I don't understand the distinction between these two.

> and potentially other existing type units on the system to avoid
> confusions and conflicting naming scheme,

system and user units are completely unrelated to each other. Of
course naming them poorly could cause some confusion. This was the
main reason for proposing some sort of prefix or suffix, like
graphical-$SESSION.target or $SESSION-session.target or so. This does
not need to be firmly defined, and systemd itself does not need to
know about it, but it might still be useful to give a recommendation
so that the various desktop sessions have some naming consistency.

> since Desktop Environments will need to have their own targets so based on
> my comments on this and for Gnome ( on Fedora ) and on the type units you
> are creating in your script ( that all have to reside in
> ~/.config/systemd/user/ directory for all the desktop environment user type
> units right )

I just used ~/.config/systemd/user/ for my test script. Obviously
actual packages would ship them in /usr/lib/systemd/user/.

> so this would become something along the lines of
> 
> # gnome.target
> 
> [Unit]
> Description=Gnome Desktop Environment
> Documentation=https://wiki.gnome.org/
> Requires=multi-user.target
> Wants=gdm.service
> Conflicts=rescue.service rescue.target
> After=multi-user.target rescue.service rescue.target gdm.service
> AllowIsolate=yes

I still think you are confusing user and system units here.
*Everything* in this thread (like gnome.target) is about *user*
systemd units. The above are all system units -- the user instance
does not know about gdm, rescue.service, etc. So this unit wouldn't
work at all.

Or asked the other way around, why do you need a gnome.target on the
system side? There might very well be reasons why you want to split
the system graphical.target into DE specific ones, to make it easier
to start the correct DM. However, this is unrelated to how to start
stuff *in* the graphical session.

> # 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.

> 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.

> 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.

Hence my idea of a graphical.target user unit which would act like an
alias, as it starts and stops together with whatever-session.target.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)