Bug#772555: untested hacky attempt at using systemctl preset

[Felipe Sateler]

On 4 March 2016 at 12:12, Andreas Henriksson <andreas at fatal.se> wrote:
> Hello Raphael,
>
> On Fri, Mar 04, 2016 at 03:36:54PM +0100, Raphael Hertzog wrote:
>> Hello Andreas,
>>
>> thanks for working on this patch!
>>
>> I want to test your patch in Kali and make it ready for inclusion. But
>> there are things that I don't really understand...
>>
>> On Wed, 02 Mar 2016, Andreas Henriksson wrote:
>> > Please note that perl warns about the smartmatch being experimental.
>> > Someone should probably replace that part with a better check....
>>
>> So I have read about what smartmatch does... but basically I think it
>> does not do what you wanted to do. So can you tell me what you wanted
>> to test?
>
> The end result is only used for "changed something" (or not).
>
> See: $changed_sth = ...
>
> I left the inital attempt commented out which might help clarify this a
> bit. See the commented "is_enabled" calls and comparison.
> I realised that simple comparison is not correct since the unit you're
> operating on could possibly be unchanged status while something else
> changed (eg. an underlying unit which got pulled in via Also=).
>
> Example: unit foo.service contains Also=bar.service, foo.service is already
> enabled (because previous versions did not have the Also=bar.service?)
> while bar.service is not. Running "systemctl preset foo.service" (via
> updating the foo-package containing foo.service) will lead
> to bar.service becoming enabled while foo.service status is unchanged.
> Now $changed_sth must be set to true so that systemctl daemon-reload
> gets called to reload the new status.

Note that daemon-reload is automatically called by preset, unless:

- Running in a chroot
- Or, not running under systemd
- Or, a --root parameter was passed
- Or, --global is passed
- Or an unsupported envvar is set.


I think the daemon reload can simply be hardcoded to 0 when running preset.

>
>>
>> I assume you wanted to compare both data structures and just know whether
>> they contain the same thing or not. But the structure is an array of
>> hashes. So the smart match compares each hash individually, but the hash
>> comparison only ensures that both hashes have the same keys (and does
>> not check the values). So basically the smart match will always return
>> true.
>
> I'm not sure it's that important to actually detect changes, maybe
> we should just hardcode this:
>
> $changed_sth = 1;
>
> This seems to just lead to a "systemctl daemon-reload" which shouldn't
> be the end of the world if it runs even when not needed.

This is only needed when creating links manually. As noted above, when
invoking via systemctl it does the reload automatically.


-- 

Saludos,
Felipe Sateler