Bug#1014115: uninstall does not properly remove enablement symlinks

[Michael Biebl]

Am 30.06.22 um 18:18 schrieb Michael Biebl:
> Am 30.06.22 um 17:31 schrieb Luca Boccassi:
>> On Thu, 30 Jun 2022 at 15:44, Michael Biebl <biebl at debian.org> wrote:
>>>
>>> Am 30.06.22 um 16:32 schrieb Luca Boccassi:
>>>> On Thu, 30 Jun 2022 at 15:24, Michael Biebl <biebl at debian.org> wrote:
>>>>>
>>>>> Am 30.06.22 um 16:13 schrieb Luca Boccassi:
>>>>>> On Thu, 30 Jun 2022 at 15:08, Michael Biebl <biebl at debian.org> wrote:
>>>>>>>
>>>>>>> Am 30.06.22 um 14:26 schrieb Michael Biebl:
>>>>>>>> This might be a bug in i-s-h, but filing against systemd-homed for
>>>>>>>> now.
>>>>>>>>
>>>>>>>> systemd-homed.service:
>>>>>>>> [Install]
>>>>>>>> WantedBy=multi-user.target
>>>>>>>> Alias=dbus-org.freedesktop.home1.service
>>>>>>>> Also=systemd-homed-activate.service systemd-userdbd.service
>>>>>>>>
>>>>>>>> systemd-homed-activate.service:
>>>>>>>> [Install]
>>>>>>>> WantedBy=systemd-homed.service
>>>>>>>> Also=systemd-homed.service
>>>>>>>>
>>>>>>>> → we have a circular dependency here, maybe deb-systemd-helper 
>>>>>>>> get's
>>>>>>>> confused by that
>>>>>>>
>>>>>>>
>>>>>>> I just checked that we can mitigate this issue by removing this 
>>>>>>> circular
>>>>>>> Also= dependency. It is indeed deb-systemd-helper getting 
>>>>>>> confused by
>>>>>>> that and as a result not writing proper state files to
>>>>>>> /var/lib/systemd/deb-systemd-helper.
>>>>>>> So the damage is already done during installation in postinst.
>>>>>>> Thus raising to RC to warn users from installing systemd-homed atm.
>>>>>>>
>>>>>>> I propose a patch like the attached one, i.e. dropping the Also= 
>>>>>>> from
>>>>>>> systemd-homed-active.service. WDYT?
>>>>>
>>>>> Are you against shipping this patch for the time being until we have a
>>>>> proper fix?
>>>>
>>>> Given the problem is that i-s-h doesn't generate the correct postinst,
>>>> can we instead add a workaround to the postinst itself?
>>>
>>> No, it's not an incorrect postinst. The generated postinst code looks
>>> fine afaics.
>>>
>>> It's deb-systemd-helper failing in postinst [1] (due to the circular
>>> Also=) and subsequently not writing any state files to
>>> /var/lib/systemd/deb-systemd-helper (which means it can't clean up the
>>> state on purge).
>>>
>>>
>>> I'm pasting the error message again, for reference
>>>
>>>> Setting up systemd-homed (251.2-7) ...
>>>> Created symlink 
>>>> /etc/systemd/system/systemd-homed.service.wants/systemd-homed-activate.service 
>>>> -> /lib/systemd/system/systemd-homed-activate.service.
>>>> Created symlink 
>>>> /etc/systemd/system/dbus-org.freedesktop.home1.service -> 
>>>> /lib/systemd/system/systemd-homed.service.
>>>> Created symlink 
>>>> /etc/systemd/system/multi-user.target.wants/systemd-homed.service -> 
>>>> /lib/systemd/system/systemd-
>>>> homed.service.
>>>> Deep recursion on subroutine "main::get_link_closure" at 
>>>> /usr/bin/deb-systemd-helper line 253, <$fh> line 23.
>>>> /usr/bin/deb-systemd-helper: error: unable to read 
>>>> /lib/systemd/system/systemd-homed.service
>>>> Deep recursion on subroutine "main::get_link_closure" at 
>>>> /usr/bin/deb-systemd-helper line 253, <$fh> line 41.
>>>> /usr/bin/deb-systemd-helper: error: unable to read 
>>>> /lib/systemd/system/systemd-homed-activate.service
>>
>> I see, then could it be fixed in the postinst manually after the calls
>> added by the helper?
> 
> I don't see how.

Let me put this differently: this would mean manually implementing in 
shell what deb-systemd-helper is doing in perl and creating the state 
files ourselves.
Feasible, yes. Doable, I'd say no.
I'd rather prefer a one-line patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220630/61f2e621/attachment.sig>