On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche <didro...@ubuntu.com> wrote: > The thing I'm afraid of that we won't have a single place to list all > disable units, and they will be in multiple packages, so (as I'll repeat > below), I'm unsure that we would able to only load the preset as once shot, > as we may add some preset files as part of packages later on with the > current structure (to disable more units by default).
I'm not familiar with Debian packaging, but the way I would imagine this working would be to call preset once all the packages in your transaction have been installed. That way, no matter which package ships the preset files, whatever preset files are installed by the time your current upgrade/install transaction completes are what will determine if a certain unit should be enabled. Of course, if you install first your package, and then in a separate transaction install some preset files with overrides, these will not be applied retroactively, but I would fond that behaviour very surprising to be honest. Of course, it would still be possible to do a retroactive preset thing with some amount of hacking, but I'm really not convinced that it makes sense to explicitly support upstream. >> This is up to the distro I guess, but I would have thought that >> presets should only be applied on install-time, and not on upgrade. > > You mean system install time, right? Having it one shot would be more > complex in our case I think as stated above (I guess, we'll have the disable > distributed in multiple packages, not all being installed by default). I meant package-install time (which may be different from system-install). I.e., after every package transaction, do the presets on all newly installed packages. >>> agreed as well, or, this would be a way for the sysadmin to "stick" this >>> unit/service whatever future distro will choose in the next upgrade. >> >> Could be, yeah, but moving from static to opt-in during an upgrade >> sounds like a packaging bug to me, so hopefully this situation would >> never be encountered in production. > > It should not happen in production, indeed, but packaging errors happen and > we should maybe be able to recover without having impacts on admins who > systemctl enable this unit in particular for their needs? What I meant is that it sounds strange for admins to be proactively enabling static units if the policy is that they should never be automatically disabled on upgrade. We may still want to make this as smooth as possible for those who do, but I just doubt it will be a common thing to do. > Let's say as an admin that I want to disable plymouth-quit.service (which is > a static unit file and symlinked in /usr/lib… on the multi-user target). > Without knowing the systemd internals, my natural intent would be to use > "systemctl disable plymouth-quit.service" which is no-op in this case on a > static unit enabled on the multi-user target with the symlink shipped by the > package. This may be perceived as unnatural to him to have to use "systemctl > mask" to disable it, or am I just being too pessimistic? Right, I get it. In this case we should definitely warn when someone tries to disable a statically enabled unit. We should suggest to the user that this package is not meant to be disabled, but one can use masking instead (voiding the warranty, etc, etc). Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel