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 (didro...@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?). 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 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.
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?
Finally, on the "know what the administrator did on this machine", here
are two cases that we can identify:
I. if the administrator removes the service package, we usually keep
current service state (enabled/disabled) on reinstall.
So:
<foo.service> enabled by default
1. systemctl disable foo.service
2. apt-get remove foo
3. apt-get install foo
-> foo should still be disabled. However, that won't be the case as on
reinstall, systemctl preset will re-enable the service as of the preset
policy.
Indeed, we don't have any record that the admin disabled it compared
default distro policy as there is no difference between: "no previous
installation state" and "service being disabled state" (no symlink).
Same for enabling a service that is by default disabled: next systemctl
call on reinstall will remove the symlinks (Alias included).
II. if the adminstrator purges the service package, we usually expect
that reinstalling it will reset the service to the default
enablement/disablement state.
So:
<foo.service> enabled by default
1. systemctl disable foo.service
2. apt-get remove --purge foo
3. apt-get install foo
-> foo should be enabled as this is the default state in distro.
This use case works because the previous one doesn't :)
So, I think we should really be able to fix case I. Also, we would have
to condition the systemctl preset call (we have idempotent postinst
script, and need to track new installs from upgrade, as we run those
during postinst configure). We proposed the separate /usr vs /etc as
this would have been a simple way to know what the admins changed
compared to the default. Any idea on how we can solve that with the
existing concepts?
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
