Your message dated Sat, 11 Jul 2026 12:06:46 +0100
with message-id <[email protected]>
and subject line Re: Bug#1141854: libselinux1: fails to upgrade in initless
chroots
has caused the Debian Bug report #1141854,
regarding libselinux1: fails to upgrade in initless chroots
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1141854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141854
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libselinux1
Version: 3.11-1
Severity: serious
As had been noticed in #1140305[1], upgrading systems where no provider
of systemd-tmpfiles has been installed yet fails due to a circular
dependency. See also the failed piuparts job[2] in the Salsa CI.
I am filing this bug to prevent testing migration of libselinux and
causing even more widespread upgrade failures.
-- System Information:
Debian Release: forky/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140305#30
2. https://salsa.debian.org/selinux-team/libselinux/-/jobs/9920294
--- End Message ---
--- Begin Message ---
Version: 3.11-2
On Sat, 11 Jul 2026 at 11:17:01 +0200, Sven Joachim wrote:
As had been noticed in #1140305[1], upgrading systems where no provider
of systemd-tmpfiles has been installed yet fails due to a circular
dependency.
I was about to suggest moving the tmpfiles.d snippet to a non-library
package, but Luca Boccassi was way ahead of me, and it seems this was
resolved in libselinux_3.11-2 by moving the tmpfiles.d snippet from
libselinux1 to selinux-utils.
That seems like an appropriate solution to me: merely installing libselinux
(or libapparmor) shouldn't try to set up system-wide integration with
SELinux (or AppArmor), and it seems more appropriate for a higher-level
package like policycoreutils (or apparmor) to be responsible for that.
smcv
--- End Message ---
