[DSE-Dev] Bug#914247: Please move library to /usr/lib

[Helmut Grohne]

Control: user hemlutg at 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
-------------- next part --------------
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 <helmut at 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 <russell at 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,