Le mardi 27 janvier 2015 à 06:21 +0300, Andrei Borzenkov a écrit : > В Mon, 26 Jan 2015 16:07:37 +0100 > Frederic Crozat <[email protected]> пишет: > > > Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit : > > > * Andrei Borzenkov <[email protected]> [2015-01-26 14:47]: > > > > On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <[email protected]> > > > > 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: [email protected] To contact the owner, e-mail: [email protected]
