I note from this posting:
http://lists.fedoraproject.org/pipermail/devel/2011-July/153665.html
And this one:
http://sourceware.org/git/?p=glibc.git;a=commit;h=2666d441c2d8107b1987b86971...
that the nss_db package has been deprecated, and that the new nss_db support in glibc no longer uses Berkeley DB format.
This is a pity. I have a genuine requirement for Berkeley DB support. Specifically, I need both Linux and Solaris clients using the same database file presented over NFS. This is used for overriding UIDs, home directories and GIDs on a per-NIS domain basis where multiple NIS domains have been imported into a single Active Directory domain. We use the 'db' source in /etc/nsswitch.conf ahead of 'ldap' so that users with clashing IDs can be successfully renumbered when they log into different NIS domains.
Berkeley databases are architecture-independent, so all Linux and Solaris clients can use the same db files. Moreover, I have forked the original version 2.2 nss_db with all the latest patches I could find and ported to Solaris at the URL below. This version compiles ok on both Solaris 10 and RHEL 5.5 (no reason why it shouldn't continue to compile on all versions of Linux that it previously did):
Full details about this port can be found in this posting:
http://sourceware.org/ml/libc-help/2011-12/msg00001.html
By moving away from a Berkeley DB format, we're left in a position where Fedora (and in the future RHEL) will not be compatible out-of-the-box with our NSS database files. This will force us to use the nss_db fork above on RHEL7 in the future, to maintain compatibility. This would be a shame, unless Red Hat supported the above module.
Perhaps there is a better solution here? Can the nss_db fork above be included as an option in Fedora? Perhaps you can simply rename the module to something other than libnss_db so that it doesn't clash with the new glibc module. Although personally I wish that glibc renamed their version so that libnss_db continues to be compatible with Berkeley DB, I'm not sure why it was considered ok to break backwards compatibility and force users of nss_db to recreate their databases to a format that was no longer cross-platform.
Opinions? Ideas?
Best regards, Mark.
On Wed, Dec 14, 2011 at 8:16 AM, Mark R Bannister mark@proseconsulting.co.uk wrote:
I note from this posting:
http://lists.fedoraproject.org/pipermail/devel/2011-July/153665.html
And this one:
http://sourceware.org/git/?p=glibc.git;a=commit;h=2666d441c2d8107b1987b86971...
that the nss_db package has been deprecated, and that the new nss_db support in glibc no longer uses Berkeley DB format.
I appreciate your concerns, but unfortunately most of the glibc development decisions happen in the upstream glibc community, and we in Fedora don't always have a lot of pull when it comes to those sorts of decisions. Have you expressed your concerns directly to the glibc community?
-- Jared Smith Fedora Project Leader
On 12/14/2011 08:44 AM, Jared K. Smith wrote:
I appreciate your concerns, but unfortunately most of the glibc development decisions happen in the upstream glibc community, and we in Fedora don't always have a lot of pull when it comes to those sorts of decisions.
That reminds me that you were talking to the glibc upstream about their sometimes cavalier attitude to significant changes. How did that go? Did you get a sense that they understood where we're coming from?
On Wed, Dec 14, 2011 at 9:48 AM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
That reminds me that you were talking to the glibc upstream about their sometimes cavalier attitude to significant changes. How did that go? Did you get a sense that they understood where we're coming from?
My discussion with the glibc maintainers was purely a technical one -- centered specifically around the practices and procedures of doing development in rawhide and not making invasive changes on released branches. As a result of my conversations, we now have a new glibc package maintainer in Fedora (Jeff Law), who sees eye-to-eye with me on the need to not make invasive changes in packages on released branches. I consider that a very good thing, and we've already started to see the benefits of not re-syncing glibc with upstream head every time we push out a new package. The "doing development in rawhide" piece hasn't fully come about yet, but I'll be continuing my discussions around that piece of the puzzle.
But to go back to the heart of your question -- my discussions with upstream did *not* center on attitudes. It focused on best practices for effective and efficient development. And in that regard, I think we've got as strong of a trust relationship between Fedora and the glibc packager as I've seen in a long time.
-- Jared Smith Fedora Project Leader
On 12/14/2011 10:02 AM, Jared K. Smith wrote:
On Wed, Dec 14, 2011 at 9:48 AM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
That reminds me that you were talking to the glibc upstream about their sometimes cavalier attitude to significant changes. How did that go? Did you get a sense that they understood where we're coming from?
But to go back to the heart of your question -- my discussions with upstream did *not* center on attitudes. It focused on best practices for effective and efficient development. And in that regard, I think we've got as strong of a trust relationship between Fedora and the glibc packager as I've seen in a long time.
Sorry, my wording was awkward. I was thinking about the coordination issue, not about emotional attitudes. I'm glad it's been addressed.
-
Jared K. Smith -
mark＠proseconsulting.co.uk -
Przemek Klosowski