On Thu, 30 Jun 2022 at 15:24, Michael Biebl <bi...@debian.org> wrote: > > Am 30.06.22 um 16:13 schrieb Luca Boccassi: > > On Thu, 30 Jun 2022 at 15:08, Michael Biebl <bi...@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 > >
