Control: tags -1 patch
On Mon, 2022-09-19 at 13:35 +0200, Andreas Beckmann wrote:
> On 19/09/2022 12.07, Marco d'Itri wrote:
> > The main issue can only be fixed in the libc packages (which would
> > be
> > wonderful, because then we could stop creating the biarch links and
> > directories on all systems).
>
> on amd64:
>
> # apt-file search -x '^/lib32' | cut -d: -f1 | sort -u
> lib32ncurses6
> lib32ncursesw6
> lib32readline8
> lib32tinfo6
> libc6-i386
>
> # apt-file search -x '^/libx32' | cut -d: -f1 | sort -u
> libc6-x32
>
> # apt-file search -x '^/lib64' | cut -d: -f1 | sort -u
> libc6
>
> # apt-cache show lib32ncurses6 lib32ncursesw6 lib32readline8
> lib32tinfo6
> > grep -E 'Package|Depends'
> Package: lib32ncurses6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32ncursesw6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32readline8
> Depends: readline-common, lib32tinfo6 (>= 6), libc6-i386 (>= 2.33)
> Package: lib32tinfo6
> Depends: libc6-i386 (>= 2.33)
>
> Just brainstorming:
> If we declare libc6-i386 as the "owner" of /lib32, lib32* as "users"
> of
> /lib32 and add libc6-i386.preinst that
> * handles the creation of /lib32 if missing, either as directory or
> symlink, depending of the state of /lib
> * errors out (or converts) if /lib32 is a directory but /lib is a
> symlink
> and then have all "users" of /lib32 Pre-Depends: libc6-i386 (>= xxx)
> (might need a debhelper patch to populate ${misc:Pre-Depends})
> and lintian check for such a pre-depends ...
> (I'm not sure if a plain Depends is sufficient to ensure
> libc6-i386.preinst gets run in all cases before some lib32* gets
> unpacked ...)
> Same for /libx32, except that there are no users that might need
> updating.
>
> How likely is it that a user of /lib32 gets unpacked during the early
> bootstrapping phase? If that is not going to happen, the symlink
> creation for /libxx could be deferred to the installation of
> libc6-{i386,x32} and no "unowned" /libxx symlinks would be lingering
> around after boostrapping.
>
> On i386 we have
>
> # apt-file search -x ^/lib64 | cut -d: -f1 | sort -u
> lib64gcc-s1
> lib64ncurses6
> lib64ncursesw6
> lib64readline8
> lib64tinfo6
> libc6-amd64
>
> # apt-file search -x ^/libx32 | cut -d: -f1 | sort -u
> libc6-x32
>
> (and no /lib32)
>
> Didn't check other architectures.
>
> Interesting could also be the installation of libc6:amd64 on a i386
> system as that will create /lib64 ... yes, that will leave you with a
> /lib64 directory if no symlink pre-exists.
This MR implements the suggestion from Marco from earlier in this
thread [0]:
https://salsa.debian.org/glibc-team/glibc/-/merge_requests/11
Tested with libc6-i386, seems to do the expected thing. We can remove
it then after everything has moved to install only to /usr, hopefully
in Trixie.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699#77
--
Kind regards,
Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part