On 01/26/2015 01:20 PM, Raymond Wooninck wrote:
On Monday 26 January 2015 12:58:29 Jiri Srain wrote:
leaving out YaST, what would be the default workflow for user who just installs a single desktop manager?
I assume you are talking here about the second proposal. This would mean that we need to set a default display-manager at installation time. This would be the same as the current situation. If I now remove GDM and replace it with KDM, then I need to make changes in the sysconfig area to reflect this. But the LIVE-cd's would come with a default setup, so this would not change.
Yes, I talk about the 2nd proposal. I may be wrong, but I believe that there is some magic in the scipts which has some kind of fallback. And, honestly, I think that this is something that should keep working.
How should the validation be done? Have will the mapping between the device manager and unit file work?
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.
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. 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.
I'm not saying that your proposal is wrong, no way. However, I definitely want to avoid having "if DM is foo, install package bar" in the YaST code and I'd like package operations via rpm or zypper produce expected results.
That was just an example. We could also have YaST detect the installed unit files to see which display-managers are available on the system. Which would be a big improvement, as that today I can set whatever command or whichever display-manager in the sysconfig and the script will try to start it (and of course if it is not there it will simply fail).
If we want to be fool-proof and that we have predictable results when we install a display-manager package, then we should go for option 1. Again today I can install GDM, SDDM, KDM, lightdm all at the same time and still have a failing system as that in sysconfig I have blabla set as the default display-manager.
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. 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