Bug#1014115: uninstall does not properly remove enablement symlinks

Luca Boccassi bluca at debian.org
Thu Jun 30 15:32:13 BST 2022


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?

> >> I've also cloned the issue for i-s-h, as we might want to fix that
> >> properly. My perl is a bit rusty, so would appreciate help with that.
> >>
> >> @bluca: do you think the attached patch is suitable for upstream?
> >>
> >> I find this circular Also= dependency kinda odd, I have to admit.
> >
> > I don't think so, this seems clearly a bug in i-s-h. Ideally we should
> > really drop all of that and just use presets as RPMs do... but it's a
> > lot of work.
>
> We have i-s-h/deb-systemd-helper for a couple of reasons (none of which
> can be solved by presets afaics)
>
> - distinction between uninstalled/purged state in Debian.
> We want to ensure that if you have a install/remove/install sequence,
> the enablement state of the service is preserved.
> For that we need to keep additional state, that is only removed on purge.
> If we remove the enablement symlinks on remove, we can't preserve the state.
> If we remove the enablement symlinks on purge, the service files are no
> longer around, so we can't do a proper cleanup.

i-s-h could be reduced to ship snippets that simply maintain this
state after a remove till the next install/purge?

> - masking a service upon uninstallation
> This is a sad reality, as packages still ship legacy SysV init scripts
> which are conffiles and would suddenly become active if a package is
> removed but not purged.

At some point we should just nuke the sysv unit generator upstream.
It's been 10+ years, there was plenty of time to add native units
where needed.
Then this becomes moot - the old init scripts would be just inert when
booting under systemd.

> I certainly would like to get rid of i-s-h, but I don't see how that is
> doable.
>
> Regards,
> Michael
>
>



More information about the Pkg-systemd-maintainers mailing list