Mailinglist Archive: yast-devel (100 mails)

< Previous Next >
Re: [yast-devel] Replacement proposal for the current display-manager.service
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
sddm.service.

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

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

Raymond
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups