Control: user heml...@debian.org Control: usertags -1 + dep17m2 On Thu, Nov 18, 2021 at 04:56:31PM +0000, Simon McVittie wrote: > Control: tags -1 + trixie > > On Tue, 20 Nov 2018 at 22:38:21 +0100, Michael Biebl wrote: > > since late-mounted /usr is no longer supported, the artifical split > > between /lib and /usr/lib no longer is really useful. > > Therefor please consider moving the libraries to /usr/lib. > > As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 please > don't make this change at the moment: there's a risk of it disrupting > the transition to merged-/usr.
Thanks for having waited. The moratorium has since been delegated to https://wiki.debian.org/UsrMerge and we now allow some moving. Since libselinux1 is part of the pseudo-essential set, we must be very careful. https://subdivi.de/~helmut/dep17.html gives details on possible problems. For the libselinux source package, there is fortunately just one affected file in one affected package. Since libselinux1 is Multi-Arch: same, we must pay attention to DEP17 P7, but since the library is on a multiarch path this does not apply. We also must pay attention to DEP17 P1, this poses a real risk to the 2038 transition, because it might rename the library package to libselinux1t64 while keeping the name. According to https://wiki.debian.org/ReleaseGoals/64bit-time, libselinux is not in the not-affected list. Therefore, please upload the time64 change to experimental and have it wait there for at least three days. Very likely, this will have to be mitigated. Since we cannot use Conflicts between essential packages (DEP17 M7), we must use protective diversions (DEP17 M8). Please get in touch with me at that time. Since there also is a udeb package, we must be careful to not break the debian-installer (DEP17 P10), but the library search path includes /usr/lib/$multiarch even on unmerged systems. Finally, we must be careful about filesystem bootstrap (DEP17 P8). I locally verified this aspect. Therefore, I think we really are careful enough now and can move ahead. You have two options to implement this. In the long term, I recommend Michael's patch. If there is a risk of backporting libselinux to bookworm, I recommend using dh_movetousr instead, because it automatically moves libselinux1 back below /lib in the event of a backport. In any case, please go ahead with this and keep this in mind when doing the time64 upload (regardless of which patch you use). Helmut
diff --minimal -Nru libselinux-3.5/debian/changelog libselinux-3.5/debian/changelog --- libselinux-3.5/debian/changelog 2023-07-09 23:50:22.000000000 +0200 +++ libselinux-3.5/debian/changelog 2023-11-14 09:33:40.000000000 +0100 @@ -1,3 +1,10 @@ +libselinux (3.5-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move libselinux.so.1 to /usr. (Closes: #-1) + + -- Helmut Grohne <hel...@subdivi.de> Tue, 14 Nov 2023 09:33:40 +0100 + libselinux (3.5-1) unstable; urgency=medium [ Laurent Bigonville ] diff --minimal -Nru libselinux-3.5/debian/control libselinux-3.5/debian/control --- libselinux-3.5/debian/control 2023-07-09 23:50:22.000000000 +0200 +++ libselinux-3.5/debian/control 2023-11-14 09:33:37.000000000 +0100 @@ -8,6 +8,7 @@ Russell Coker <russ...@coker.com.au> Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13), + dh-sequence-movetousr, dh-sequence-python3 <!nopython>, dh-sequence-ruby <!noruby>, file,