[systemd-devel] /usr vs /etc for default distro units enablement

[Colin Guthrie]

Andrei Borzenkov wrote on 19/11/14 17:49:
> В Tue, 18 Nov 2014 16:22:18 +0000
> Colin Guthrie <gmane at colin.guthr.ie> пишет:
> 
>> Michael Biebl wrote on 18/11/14 15:55:
>>> 2014-11-18 16:30 GMT+01:00 Colin Guthrie <gmane at colin.guthr.ie>:
>>>> Michael Biebl wrote on 18/11/14 15:09:
>>>>> 2014-11-18 15:59 GMT+01:00 Colin Guthrie <gmane at 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/