Andrei Borzenkov wrote on 19/11/14 17:49: > В Tue, 18 Nov 2014 16:22:18 +0000 > Colin Guthrie <gm...@colin.guthr.ie> пишет: > >> Michael Biebl wrote on 18/11/14 15:55: >>> 2014-11-18 16:30 GMT+01:00 Colin Guthrie <gm...@colin.guthr.ie>: >>>> Michael Biebl wrote on 18/11/14 15:09: >>>>> 2014-11-18 15:59 GMT+01:00 Colin Guthrie <gm...@colin.guthr.ie>: >>>>>> Didier Roche wrote on 18/11/14 13:58: >>>>>>> This would be maybe a nice way for the admin to know what's coming from >>>>>>> a distribution default or not. However, let's say I want to ensure that >>>>>>> ssh will always be available on my server, I would (even if it's in my >>>>>>> server preset) then systemctl enable openssh, no matter whatever future >>>>>>> preset updates does (like disable it in the next batch upgrade). >>>>>> >>>>>> For the avoidance of doubt, I believe that running systemctl preset >>>>>> should only ever happen on *first* install, never on upgrade or such >>>>>> like. >>>>>> >>>>> >>>>> And what are you going to do, if the unit file changes? >>>>> Say v1 had >>>>> >>>>> [Install] >>>>> WantedBy=multi-user.target >>>>> >>>>> and version B has >>>>> [Install] >>>>> WantedBy=foo.target >>>> >>>> >>>> Well this is an edge case I'm sure you'll agree. >>> >>> Actually, in the short period of time (and with the currently still >>> low number of packages shipping native units) in Debian, this happened >>> more often then I'd have expected. >>> >>> So I think we should have a better answer then just saying this is an edge >>> case. >> >> I still thing we should still call it an edge case tho' :) >> >> Having a way around it is fine tho'. >> >>>> Ultimately, with this case, doing the preset is wrong anyway. You don't >>>> want the distro choice, you want the "what the user had" choice. >>> >>> You only want to preservce the user choice, if it deviated from the >>> distro choice. >> >> Well, depending on implementation that's one and the same thing. With >> the current implementation of preset, they *are* the same thing, > > Not really. There is no way to distinguish between unit enabled by > presets and unit enabled by admin.
Indeed, but is this an important distinction? If a user installs something knowing the distro policy is to not enable a service on install they will perhaps quite happily observe this behaviour (perhaps rebooting several times) and indeed rely on it (perhaps not wanting it enabled for whatever reason). If the package is subsequently updated and it's individual policy changes to enable the service by default (or even if the distro policy is updated to change to enabling services by default), do you want to know that the user has not *changed* anything or do you want to know that the user has *observed* anything? The latter is obviously much harder to tell! Personally, I believe that once the package is installed, everything moves over to user/admin decisions. Regardless of whether the user has consciously enabled or disabled anything, their system is running in a particular way and packages or a change of distro policy should not mess with that later. So while I agree with your statement, I'm not sure it actually matters. I certainly strongly disagree with the original statement "You only want to preservce the user choice, if it deviated from the distro choice." If the user has *observed* the distro choice in anyway, they are now relying on it. You cannot and should not go messing with that later. (Of course there may be valid exceptions for that but these IMO should be strongly discouraged. In those special cases you'd maybe even want warnings to be shown to the user before altering anything and perhaps give the user veto powers. But on the whole I don't think I've yet heard a good argument for creating an infrastructure that allows to change things *after* initial install automatically, even if package or distro policy changes.... after a factory reset I'd agree it should take on the new defaults, but not on a stateful system during package upgrades) Again, just my opinion and there may very well be good counter arguments. 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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
