Le 05/12/2014 16:42, Lennart Poettering a écrit :
On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote:
This would also only "fix" the newly installed case, not the upgrade with
new distro defaults or various purge vs remove ones. That's why I think some
kind of previous state db can help getting all those requirements met as you
propose, and doing some comparisons between states (only when they deviated
from defaults).
Then, we can run preset on packages that matches previous defaults (meaning:
where the admin didn't override the default choice) as a dpkg trigger (when
new units are installed/upgraded and on a new/updated preset file shipped).
Would that makes sense?
Not sure I grok what you are proposing. I'd be very careful with
keeping yet another layer of service enablement states (even if just
as "history") in systemd upstream.
I can clearly understand why you don't want to have a database of
previous default enablement status. (that's what debian/ubuntu is doing
right now in /var, having a bunch of symlinks to keep default state).
There are 3 cases that we want to have supported (ideally with preset-only):
1. upgrade with default policy change:
* foo.service is enabled in a target (with an [Install] section). Preset
says 'enable *' (== no preset stenza) by default.
* sysadmin didn't enable/disable it.
* an upgrade of a package (not necessarily the package containing
foo.service) ships a new preset file with "disable foo.service"
-> We should have then foo.service disabled as per preset choice.
2. upgrade with dependency change:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin didn't enable/disable it.
* After an upgrade, the unit contains WantedBy=baz.target (still enabled
by default)
-> We have it still enabled by enabled (as per preset choice), with
.wants symlink from baz.target
From those 2 cases, we could say: "just run systemctl preset on every
package upgrade or preset change", however, there is as well this case:
3. upgrade with default changes, but sysadmin overrides:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin run systemctl disable foo.service (or mask it)
* After an upgrade, the unit contains WantedBy=baz.target (still enabled
by default preset policy)
-> We shouldn't have foo.service enabled back as the admin did disable it.
That's why I was evocating keeping a previous state database to detect
"previous default state == current state", and only run preset on the
package in that case (and new installs).
Is this more clear? Any other idea of on an elegant way of handling
those without having the previous state database? (in an upstream
compatible way, if possible)
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
