Mailinglist Archive: yast-devel (100 mails)

< Previous Next >
Re: [yast-devel] Replacement proposal for the current display-manager.service
  • From: Jiri Srain <jsrain@xxxxxxx>
  • Date: Mon, 26 Jan 2015 14:43:56 +0100
  • Message-id: <>
On 01/26/2015 02:01 PM, Raymond Wooninck wrote:
On Monday 26 January 2015 13:35:07 Jiri Srain wrote:
What validation ? The unit files that are being delivered from upstream
all set the alias display-manager.service. So this means that if I
install the SDDM display-manager, the sddm.service unit file is placed in
the systemd directories. When I call systemctl enable sddm.service, then
this would create the display-manager.service pointing to the

My understanding was that you wanted to ship the service files
separately to assure that only one of them is installed.

No, the service files are shipped inside the package of the DM itself (as
intended by upstream). So the GDM package would contain the gdm.service file
itself and the KDM package would contain the kdm.service file.

If we opt for option 1, then the installation of the KDM package would have
the systemd macro's inside the %post and %postun scripts to install and enable
(resp. disable and remove) the service file. This would then create the
display-manager.service which is required by systemd.

What happens if I uninstall (just via plain rpm -e) the currently
selected DM?

Then the start of the display-manager will fail. But this is exactly as
what happens now.

I'm not sure (and even if it is, IMO this is a bug), anyway, I will not
argue here since I have not tried that.

I tried to read the script that display-manager.service is currently starting
and I am not sure what will happen. But if the script does fallback on
something, then this is xdm and nothing else.

This makes most sense. Unlike with YaST (where the start-up script knows and hardcodes all back-ends), it is not the case here.

This would mean that when a display-manager is uninstalled, we could enable
the xdm.service by default. This would leave the user always with a display-
manager as that I assume that the xdm package already has plenty of requires
to have the similar setup at this moment.

I think that this is reasonable behavior. I would prefer that if any DM remains installed, it will be used, though.

Regardless what the implementation is, I prefer the behavior of YaST's
script: If the selected (be it via sysconfig or any other way) UI
front-end is available, use it. Otherwise, try the others.

Since when is YaST doing this ? The current scipt used to start the display-
manager is provided with the XDM package. YaST just uses the sysconfig editor
to set a variable inside the /etc/sysconfig/displaymanager file. YaST does
this without checking anything and even on a system that doesn't contain GDM
or KDM, I am still able to set one of those as the default DM. And upon a
reboot I get a big surprise as that XDM will start. So this is then actually a
YaST bug !

I was talking about the /sbin/yast2 script - which starts YaST itself. If the built-in logic decides (possibly even based on sysconfig value) to run Qt but Qt is not available, it tries Gtk and NCurses.

I'd strongly prefer to have a fool-proof solution. Even with your
proposal, I can imagine behavior like:
- when installing the first DM, just make it default
- when uninstalling default DM, make another one default

If you decide to put this logic into YaST, you will have to replicate it
for building the live images and in any case where YaST is not involved
- which should IMO be avoided.

Based on this feedback it seems that it would be better/easier to build the
logic into the DM packages itself and to drop the functionality from YaST
completely. If we would go for using update-alternatives (as proposed by
Ludwig), then I could imagine something like the following logic:

1) xdm package is always installed and will provide an xdm.service. Through
update-alternatives the xdm.service is installed as display-manager.service
but with the lowest priority.

2) kdm, gdm, lightdm, sddm, etc packages will provide their unit files and
will install their respective unit-files. Upon installation it will create an
alternative with a higher priority than the xdm alternative. The question here
would be which one has the highest priority ? What would happen if I install
two DM's at the same time (which one would be the default) ? This could be
resolved by making the mutual exclusive, but then we are loosing the option
for the user to install multiple display-managers. Question would be however
if most of our users have actually installed more than one display-manager.
(xdm excluded).

I believe that in this case, you have two options: First wins or last wins.

I still believe that there should be a script which sets the default DM to specified one (similarly to the one in sysconfig), then you can integrate this functionality into YaST.



Jiri Srain
Project Manager
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxxx
Lihovarska 1060/12 tel: +420 284 084 659
190 00 Praha 9 fax: +420 284 084 001
Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >