Mailinglist Archive: yast-devel (100 mails)

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

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 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 >
Follow Ups