On Thu, 30 Jun 2022 at 20:20, Michael Biebl <bi...@debian.org> wrote: > > > 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 <bi...@debian.org> wrote: > >>> > >>> Am 30.06.22 um 16:32 schrieb Luca Boccassi: > >>>> 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? > >>> > >>> 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.
The problem is some files leftover, no? Just delete them in the postinst or postrm?