On Fri, Jul 10, 2026 at 05:01:47PM +0100, Colin Watson wrote: > On Fri, Jul 10, 2026 at 06:36:01PM +0300, Adrian Bunk wrote: > > On Fri, Jul 10, 2026 at 04:17:09PM +0100, Colin Watson wrote: > > > On Fri, Jul 10, 2026 at 11:57:09AM +0300, Adrian Bunk wrote: > > > > What happened is that libselinux got recompiled with the new debhelper > > > > Depends: systemd | systemd-standalone-tmpfiles | systemd-tmpfiles,... > > > > resulting in a circular dependency > > > > libselinux1 -> systemd -> libmount1 -> libselinux1 > > > > > > CCing the libselinux maintainer, since one option that's separate from the > > > wider debhelper question might be for it to sed that dependency out of > > > misc:Depends. After all, it apparently didn't have any such dependency > > > before this change, > > > ... > > > > The postinst didn't call systemd-tmpfiles unconditionally before. > > > > See #1140654 for background why your suggestion is not an option. > > Maybe not exactly as I wrote it, but there are clearly other options that > the libselinux maintainer could potentially use to unblock testing → > unstable upgrades. For example, since it's pseudo-Essential, it might be > reasonable for libselinux1 to avoid using dh_installtmpfiles and instead > copy the previous dh_installtmpfiles postinst code into its postinst and > install the tmpfiles.d snippet manually.
The status quo ante bellum was that for many years no dependency was emitted by debhelper, and the postinsts checked for systemd-tmpfiles before calling it. If we need a short-term workaround because better solution is not available, then reverting debhelper to that state is much better than asking maintainers to workaround it. cu Adrian
