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 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 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 -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org