Bug#1132249: Please build and package libnss-db from glibc

Aurelien Jarno <[email protected]> Sun, 3 May 2026 19:21:05 +0200
Newsgroups gmane.linux.debian.devel.glibc
Message-ID <afeEASover9srGZw__9054.03742087714$1777829011$gmane$org@aurel32.net>
Hi Yan,

On 2026-04-14 02:37, Fitterer, Yan wrote:
> Hi Aurelien, thank you for taking the time to look at this issue and the MR.
> 
> > One of the main reason to use the separate libnss-db package based on BerkeleyDB is that the file format is architecture independent. At that time, it was not the case of the glibc implementation. Do you know if it is still the case? This is important in the multilib and multiarch context.
> >
> > That said as db5.3 is scheduled for removal from the archive, I understand that you are investigating alternatives. One of them is libnss-cache, although the file format is quite different.
> 
> Indeed, the glibc implementation is still neither multilib nor multiarch capable. It does no byte-order handling, *and* also has issues with hash key generation (it uses a unsigned long as part of hash key generation).
> 
> That said, isn't there value in packaging the upstream glibc libnss_db.so, as an optional package, to provide a migration path for `libnss-db` users that have no multilib/mutiarch needs without forcing them to a completely different solution (libnss-cache or other) ? I'm certainly in need of a such a path, and perhaps many of the current users are. It would be nice to provide at least a partial solution. The original intent of libnss-db backend is purely as a performance enhancement on top of the local files backend. As such, in multilib environments, I think the worst case is a loss of performance in the non-native case(s), which is arguably better than losing performance in *all* cases. If `nsswitch.conf` database entries include the db backend, and the `libnss_db.so` isn't available f
 or the correct arch, it will simply skip the backend.

This is assuming that libnss-db is only used as a caching solution, and 
thus the fallback to /etc/passwd and /etc/group is acceptable. However 
there are other usages and the current libnss-db package even provides 
the /etc/default/libnss-db to configure that.

Regards
Aurelien