Hi there,

at UNIGE we use IBM Spectrum Protect (the old Tivoli Storage Manage) as
the central backup solution, on Debian-based machines via the upstream
Debian packages:

  <https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/client/v8r1/Linux/LinuxX86_DEB/BA/v8119/>

Now, `/var/lib/dpkg/info/gsk(crypt|ssl)64.postinst` checks if
`/usr/lib64` and it creates the `/usr/local/ibm/gsk8_64/lib64/lib*.so`
symlinks there.

This was not a problem on non-usrmerged Debian installations, as
confirmed by various machines of mine, since `/usr/lib64` was not
shipped/created by any package:
```
luca.capello@mantissa:~$ su -c 'etckeeper vcs log | tail -n 5' -
Password:
commit 5deed8583b1a65e9f80a9426496c2e707ce6c860
Author: Luca Capello <luca@pca.it>
Date:   Thu Dec 31 15:11:07 2009 +0100

    initial commit
luca.capello@mantissa:~$ cat /etc/debian_version
11.7
luca.capello@mantissa:~$ dpkg-query -W libc6\*
libc6:amd64     2.31-13+deb11u6
libc6-amd64
libc6-dev-i386
libc6-i386      2.31-13+deb11u6
libc6-mips32
libc6-mips64
libc6-mipsn32
libc6-powerpc
libc6-ppc64
libc6-s390
libc6-sparc
libc6-sparc64
libc6-x32
luca.capello@mantissa:~$ ls -ld /lib* /usr/lib*
drwxr-xr-x 14 root root 4096 Aug  3 23:14 /lib
drwxr-xr-x  2 root root 4096 Aug  3 23:14 /lib32
drwxr-xr-x  2 root root 4096 Aug  3 23:14 /lib64
drwxr-xr-x 64 root root 4096 Aug  4 12:29 /usr/lib
drwxr-xr-x  3 root root 4096 Feb 26  2011 /usr/lib32
drwxr-xr-x  3 root root 4096 Aug  3 23:20 /usr/libexec
luca.capello@mantissa:~$ dpkg-query -S /lib64 /usr/lib64
libc6:amd64: /lib64
dpkg-query: no path found matching pattern /usr/lib64
luca.capello@mantissa:~$ grep -r lib64 /etc/ld.so.conf*
luca.capello@mantissa:~$
```

However, on a recent Debian 12/bookworm `/usr/lib64` is now present:
```
luca.capello@gundam:~$ su -c 'etckeeper vcs log | tail -n 5' -
Password:
commit ca2981887f6f7bfdbf7030e0a33c66a910013da5
Author: root <root@gundam.pca.it>
Date:   Fri Aug 4 16:36:04 2023 +0200

    Initial commit
luca.capello@gundam:~$ dpkg-query -W libc6\*
libc6:amd64     2.36-9+deb12u1
libc6-amd64
libc6.1
luca.capello@gundam:~$ ls -ld /lib* /usr/lib*
lrwxrwxrwx  1 root root    7 Aug  4 16:28 /lib -> usr/lib
lrwxrwxrwx  1 root root    9 Aug  4 16:28 /lib32 -> usr/lib32
lrwxrwxrwx  1 root root    9 Aug  4 16:28 /lib64 -> usr/lib64
lrwxrwxrwx  1 root root   10 Aug  4 16:28 /libx32 -> usr/libx32
drwxr-xr-x 51 root root 4096 Aug  4 17:10 /usr/lib
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/lib32
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/lib64
drwxr-xr-x  6 root root 4096 Aug  4 16:31 /usr/libexec
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/libx32
luca.capello@gundam:~$ dpkg-query -S /lib64 /usr/lib64
libc6:amd64: /lib64
dpkg-query: no path found matching pattern /usr/lib64
luca.capello@gundam:~$ grep -r lib64 /etc/ld.so.conf*
luca.capello@gundam:~$
```

While the obvious solution would be for the TSM .debs...

  # echo '/usr/lib64' >/etc/ld.so.conf.d/local_tivsm_usr-lib64.conf

..,I wonder why `/usr/lib64` is not included by default.

Thx, bye,
Gismo / Luca

PS, I have looked in the BTS for already-reported bugs, the only ones I
    have found are about FHS compliance and/or u`lib64 -> lib` symlinks:

    - <https://bugs.debian.org/387446> (via <https://stackoverflow.com/questions/61205491/why-usr-lib64-is-not-in-the-default-location-of-ld-so#61216323>)
      => amd64 system not compliant with FHS
    - <https://bugs.debian.org/612000>
      => libc6: please postinst symlink /usr/local/lib64 -> /usr/local/lib for consistency with /, and /usr ones
    - <https://bugs.debian.org/632176>
      => libc6 should not provide /lib64 -> /lib symlink (amd64/kfreebsd-amd64/ppc64/sparc64)
    - <https://bugs.debian.org/626450>
      => lost /lib64 -> /lib symlink on amd64; upgrade fails
    - <https://bugs.debian.org/659064>
      => libc6 - Includes file in /lib64
    - <https://bugs.debian.org/720780>
      => libc6:amd64: /usr/local/lib64 (required by FHS) doesn't exist

Hi,

Indeed, at the time of the amd64 port was created, it was decided to use
(/usr)/lib instead of (/usr)/lib64 to install the libraries. Since then
most of them have been moved to the multiarch path, but that still
stands.

/lib64 was still necessary to store the dynamic loader as part of the
specification.

This is indeed the case, it is created by the usrmerge package, and not
shipped by glibc.

/lib64 or /usr/lib64 are not the place to put libraries on debian, so we
do not want to do that.

Regards
Aurelien

Hi,

Indeed, at the time of the amd64 port was created, it was decided to use
(/usr)/lib instead of (/usr)/lib64 to install the libraries. Since then
most of them have been moved to the multiarch path, but that still
stands.

/lib64 was still necessary to store the dynamic loader as part of the
specification.

This is indeed the case, it is created by the usrmerge package, and not
shipped by glibc.

/lib64 or /usr/lib64 are not the place to put libraries on debian, so we
do not want to do that.

Regards
Aurelien

reassign -1 usrmerge
retitle -1 usrmerge: providing /usr/lib64 breaks external software
tags -1 + wontfix

Hi,

This is even forbidden by the Debian policy to ship libraries in that
directory for 64-bit architecture, so we'll definitely do not enable
that in the libc6 package.

As the issue is actually introduced by the usrmerge package, I am
reassigning the bug there. I am also tagging it wontfix as I don't
believe the usrmerge maintainer will want to rollback the usrmerge
transition, but feel free to change that if I am wrong.

Regards
Aurelien

reassign -1 usrmerge
retitle -1 usrmerge: providing /usr/lib64 breaks external software
tags -1 + wontfix

Hi,

This is even forbidden by the Debian policy to ship libraries in that
directory for 64-bit architecture, so we'll definitely do not enable
that in the libc6 package.

As the issue is actually introduced by the usrmerge package, I am
reassigning the bug there. I am also tagging it wontfix as I don't
believe the usrmerge maintainer will want to rollback the usrmerge
transition, but feel free to change that if I am wrong.

Regards
Aurelien

Indeed.

I have used TSM for many years but I have never noticed this issue
because the upstream Debian packages are so much awful that I repackaged
the software: https://github.com/rfc1036/tivsm-deb .

Dear submitter,

as the package usrmerge has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1088212

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Paul Tagliamonte (the ftpmaster behind the curtain)