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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org