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 for the correct arch, it will simply skip the backend. > I have added a few comment to your MR. This doesn't mean it will get accepted > once fixed, we need to understand the limitation of the glibc version first. I will attend to those, and try to address them in further commits.
