[yast-devel] Replacement proposal for the current display-manager.service

older
[yast-devel] Pending Pull Requests

Raymond Wooninck

26 Jan 2015 26 Jan '15

10:43

Hi Everyone, The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started. Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working. My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself. One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use. The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files. The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager. I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred. Raymond -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Show replies by date

Jiri Srain

26 Jan 26 Jan

11:58

On 01/26/2015 11:43 AM, Raymond Wooninck wrote:

...

Hi Everyone,

The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.

Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.

My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.

One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.

The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.

The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.

Hi Raymond, leaving out YaST, what would be the default workflow for user who just installs a single desktop manager? How should the validation be done? Have will the mapping between the device manager and unit file work? What happens if I uninstall (just via plain rpm -e) the currently selected DM? 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. Jiri

...

I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred.

Raymond

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

Raymond Wooninck

12:20

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.

...

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.

...

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

Jiri Srain

12:35

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

Raymond Wooninck

13:01

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

Jiri Srain

13:43

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

Guido Berhoerster

13:42

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

* Raymond Wooninck [2015-01-26 11:44]:

...

The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.

Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.

My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.

One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.

I think that would be the worst possible option, having conflicting packages is a hassle and should be avoided at all cost, it leads to problems when people install more than one DE, makes switching between DM a pain.

...

The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.

The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.

That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working. That's also the reason why update-alternatives is not a good option apart from the problems of priorities. -- Guido Berhoerster -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Andrei Borzenkov

13:47

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...

That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Jiri Srain

14:05

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

On 01/26/2015 02:47 PM, Andrei Borzenkov wrote:

...

On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

Can't the removed package's post-uninst script do that? 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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Guido Berhoerster

14:59

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

* Andrei Borzenkov [2015-01-26 14:47]:

...

On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

I suppose that could be handled by a %postun scriptlet common to all display manager packages? -- Guido Berhoerster -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Frederic Crozat

15:07

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :

...

* Andrei Borzenkov [2015-01-26 14:47]:

...
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

I suppose that could be handled by a %postun scriptlet common to all display manager packages?

It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload. Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config). -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Andrei Borzenkov

27 Jan 27 Jan

03:21

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat пишет:

...

Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :

...
* Andrei Borzenkov [2015-01-26 14:47]:

...
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

I suppose that could be handled by a %postun scriptlet common to all display manager packages?

It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.

Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).

Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Guido Berhoerster

08:44

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

* Andrei Borzenkov [2015-01-27 04:21]:

...

В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat пишет:

...
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :

...
* Andrei Borzenkov [2015-01-26 14:47]:

...
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

I suppose that could be handled by a %postun scriptlet common to all display manager packages?

It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.

Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).

Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :)

I don't think it is much of an improvement configuring display manager behavior through /etc/sysconfig/displaymanager while having to select the actual display manager through some other mechanism like update-alternatives. -- Guido Berhoerster -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Frederic Crozat

08:53

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

Le mardi 27 janvier 2015 à 06:21 +0300, Andrei Borzenkov a écrit :

...

В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat пишет:

...
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :

...
* Andrei Borzenkov [2015-01-26 14:47]:

...
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster wrote:

...
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.

That's also the reason why update-alternatives is not a good option apart from the problems of priorities.

This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.

I suppose that could be handled by a %postun scriptlet common to all display manager packages?

It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.

Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).

Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :)

Indeed :) -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Takashi Iwai

06:44

New subject: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service

At Mon, 26 Jan 2015 11:43:56 +0100, Raymond Wooninck wrote:

...

Hi Everyone,

The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.

Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.

My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.

One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.

The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.

The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.

I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred.

How would the failsafe mode be handled in these scenarios? IOW, with your proposal, will the all features be kept and compatible? Or some must be dropped? thanks, Takashi -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

3382

Age (days ago)

3383

Last active (days ago)

List overview

Download

14 comments

6 participants

participants (6)

Andrei Borzenkov
Frederic Crozat
Guido Berhoerster
Jiri Srain
Raymond Wooninck
Takashi Iwai

[yast-devel] Replacement proposal for the current display-manager.service

tags

participants (6)