On 22 January 2015 at 16:32, Andrei Borzenkov <arvidj...@gmail.com> wrote: > В Thu, 22 Jan 2015 15:46:26 +0100 > Michael Biebl <mbi...@gmail.com> пишет: > >> 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov <dimitri.j.led...@intel.com>: >> > At the moment, I'm looking at packaging symlinks in .wants directories >> > under /usr and then allow to uninstall such a package as a means to >> > override the default config. Since I would like to update how the >> > default config is setup, without doing in /etc where I'd have to >> > answer "is this my old config, or user modified it and I shouldn't >> > touch it" >> >> That's indeed a tough problem. The upstream recommendation is, to run >> "systemctl preset" during the initial installation. >> If there are changes to the default in the unit files, those changes >> are *not* applied on package upgrades. >> >> I don't think that's a particularly compelling solution. >> >> In Debian, we introduced a helper called i-s-h [1], which keeps some >> additional state and tries to apply such changes on updates. > > There was long discussion on this just recently. > > http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html >
Thanks for this. The summary of that follows like so: generic/typical systemd units ship, with a Install section WantedBy multi-user.target an no other files. It means it is inert / disabled by default. Irrespective of the method (preset-all on empty/wiped /etc, preset at first install only, enable (generated in packaging or run by an admin), the way to enable unit is by generating appropriate .wants/ symlinks in /etc. It is viewed that distos should use presets whilst admins should use enable, however the end result is the same on disk. (E.g. distros can script things around enable/disable, and admins can write /etc/systemd/system-preset and run preset from that file). There are claims and assertions made as to what distro's should and shouldn't do -> which are distro's decisions. It is not possible to encode distro's choices with the suggested or possible semantics, neither with presets nor shipping symlinks in /usr. Then end-result is that current semantics have a bias towards "disable *" default policy. (Unit by itself is not enabled, default policy not enable, if user or preset enables, it is stored in "admin" dir /etc, rather than state dirs under "/var") The worst consequence of this, imho, is that .wants symlinks are honoured from lower level directories even if the unit is out right superseeded in a higher level directory. E.g. cp /usr/lib/systemd/system/foo*.target /etc/systemd/system; the /usr/lib/systemd/system/foo1.target.wants/foo2.target -> ../foo1.target is honoured. Nor is there a way to "move" a wants to a later target in the boot process. (e.g. most systemd intuitive way to add symlink to /dev/null & have systectl commands that mirror add-wants/add-requires) Furthermore, it appears that /etc is used as a snapshot of the preset state as it was at the last time preset-all was run essentially. On my books software state should live under /var rather under /etc. And in the current generation philosophy this breaks the assumption that "/etc" is user modified overrides only. But I think we can do better than /var. Do we really need symlinks on disk from presets? Here is a proposal: extend .wants/*; .requires/* semantics to allow removal: e.g. "if the target of the symlink in .wants/ directory points at /dev/null, instead of adding a dependency, such dependency is removed if it no longer exists" e.g. "Wants/Requires define dependencies to be added, or negating a dependency if such already exists if prefixed with "!" " e.g. add commands rm-wants / rm-requires -> which either create symlink to /dev/null in /etc/***.wants/ for dependencies created in lower-level configuration directories or removes existing symlink from /etc/***.wants/ remove preset-* commands, or support mode of operation where preset commands are no-op. instead load and apply (on boot, daemon-reload, daemon-reexec) preset directives in memory without storing a snapshot of "preset" results as symlinks in /etc. (this would make systemd stateless and be operational with less symlinks on an even a read-only /etc without even a tmpfs rw mounted /etc) This makes the policies of "enable *" and "disable *" to be in full equilibrium: - default policy applied from /usr - user override is .wants/* symlinks based on Install section -- to /dev/null to disable under enable * policy -- to a valid unit to be enabled under disable * policy -- no change in system under /usr (intentional or accidental) would loose user choice This would lead to one-time upgrade loss of state for "disable *" distributions (i.e. the small number of distro enabled by default units, which were disabled by the users, would get re-enabled. As a one time upgrade, this can be detected and acted upon appropriately). However this one time upgrade / miss-balance exaggerates the complexity inflicted upon "enable *" distributions where this problem is not for "small number of units" but for "the vast majority of units". Given that there are roughly half and half market share of "enable *" and "disable *" policy distributions - optimising for one and stating that the other one is "don't do that" is not the best choice. Also there are a lot of distributions that strike to make upgrades be the same as fresh installs, in terms of defaults applied - if defaults were not changed, new defaults should apply. Which, imho, is also the notion why all configuration should be compiled in constants or in /usr, with overrides in /run /etc and similar. -- Regards, Dimitri. - Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
