[systemd-devel] /usr vs /etc for default distro units enablement

[Colin Guthrie]

Didier Roche wrote on 02/12/14 11:50:
> Just to sum up other branches of this thread: we are trying to avoid
> having systemctl calls in debian/ubuntu postinst (or duplicated manual
> symlinks logic as we currently have).
> systemctl preset seems the cleanest path, but we want to ensure corner
> cases can be handled.
> 
> d/u policy is to enable newly installed package by default (difference
> from other distributions)
> 
> Le 02/12/2014 01:59, Lennart Poettering a écrit :
>> On Fri, 28.11.14 11:15, Didier Roche (didrocks at ubuntu.com) wrote:
>>
>>> The distribution comes preinstalled with one dm, enable * -> enable
>>> it, have
>>> the Alias=display-manager.service picking the right one.
>>> However, let's say the user installed then another dm, what happens?
>>> Both
>>> will be enabled if we systemctl preset <new_service> (as the
>>> discussion was
>>> to remove our debian enable <service> that was conditioned on the
>>> postinst).
>> "systemctl preset" will fail if there are already conflicting
>> symlinks. Hence the first installed DM wins, the second loses.
> 
> Ok, that works with the initial install case then.
> However, if lightdm is installed and the admin install gdm, he will get
> a prompt (from postinst) asking him which dm to choose. How would you
> handle that (without messing manually with the symlinks or systemctl
> enable --force in the postinst?). 

If you are giving the user a choice here specifically, then calling
systemctl enable --force is, IMO, the right thing to do.


> Writing new presets in /etc which
> enables the chosen dm and disable other, then reloading preset file to
> reset that display-manager.service alias?

I would say that the preset file would be in place for the GNOME spin
such that when it was installed, it would be enabled. The GNOME spin's
installer would likely not install lightdm in the first place and thus
gdm would get enabled when it was installed anyway (with your default
enable policy)

That said, as your policy is to enable things by default, you might want
to actually list all the dms as disable in your standard .preset file
and then have a separate .preset file to enable the appropriate dm that
is shipped with your various spins. That way, simply installing a dm is
not enough to enable it via the default policy. This guards against
needing to stop lightdm being installed on the GNOME spin - installing
would be unneeded, but not problematic - and both lightdm and gdm could
both be installed happily and only gdm would be enabled due to preset.



>>> I don't think we should have systemctl preset <new_service> running
>>> under
>>> any condition as a wipe of /etc and then "systemctl preset-all" would
>>> give a
>>> potential different result (I'm not even sure how this will work with
>>> those
>>> alias, the first matching the alias wins and get the symlinks?)
>> Dont follow? "wipe"?
> 
> I meant deleting the entire "/etc" content (or I guess as you told using
> systemctl preset-all to reset to default):
> 
> 1. lightdm and gdm were installed on my system.
> 2. gdm was enabled as the default display-manager.
> 3. I then use "systemctl preset-all"
> -> how the behavior of selecting the display-manager will be determined?
> See below implementing this with presets where enabling all services is
> the default.

Yeah, I can see this problem. I guess the setup of preset files as I
mentioned above would deal with this.

I guess the problem doesn't exist on Fedora due to it's disable *
default policy and the easiest way to get the same behaviour would be to
just list all dms as disable in your default .preset file and then
enable them all again via drop in as needed (it's not quite as clean but
it's certainly manageable IMO)


>>> We can of course have an ubuntu-desktop.preset which disables all dms by
>>> lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
>>> having those settings conflicting with each other), but it's seems
>>> that for
>>> every aliases, we need to maintain such a list (as we enable * by
>>> default)?
>> Not following here. Different flavours of Ubuntu should probably just
>> ship different preset files. (Or well, the main ubuntu should ship one
>> that enables lightdm, and then the gnome flavour ship another preset
>> file, with a lower name, tht overries the lightdm line, and enables
>> gdm instead).
> 
> You meant disable, right? As our default is to enable all services.
> So we need for any services shipping Aliases to have a preset list per
> flavor (if their behaviors differs) with:
> 99-ubuntu-desktop.preset:
> enable lightdm.service
> disable kdm.service
> disable gdm.service
> disable nodm.service
> (and whatnot… dm files in distro)
> 
> Then, we would have 01-ubuntu-gnome.preset:
> enable gdm.service
> disable lightdm.service
> disable kdm.service
> …
> 
> It seems maintaining this list in sync for all flavors would be a
> growing pain (this is a positive effect of the disable by default: you
> don't have to maintain such a list), or do you think we can come with
> something better?

I should read emails to the bottom I guess - seems you see the same
issue here :)

Yeah, I would agree that this is a bit of a pain to maintain the list,
but I don't think it's too hard either. The number of DMs is pretty
bounded, and it likely doesn't change all that often, so I don't think
it'll be too hard to maintain.

I think I've already stated my opinions on the rest of the use cases in
your email, so I'll leave that for others to comment on :)

Cheers!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/