After my list of issues related to glibc-2.14, the situation is somewhat more manageable: Mike fixed his own mistakes in the build of libtirpc, which now builds a working library, but on the other hand resolved to use a dirty hack to install the old NIS/YP header files, which are need by both libtirpc and other packages. Dirty or not, this at least produces some reasonable expectations of a working starting point.
I won’t even quote Mike’s suggestion for how to add support for libtirpc since that’s going to cause huge trouble with non-Linux platforms, given that for instances FreeBSD has a working RPC implementation (which, as far as I can tell, supports iPv6) in its C library itself. This means that what you should have in the ebuild, is probably something along these lines:
IUSE="elibc_glibc"
RDEPEND="elibc_glibc? ( || ( net-libs/libtirpc
The option of creating a virtual package for this is sweet, but unfortunately, supporting libtirpc requires the buildsystem to identify it properly. it takes a bit of work on making it possible to build against that implementation in most cases, so simply adding the virtual is unlikely to be of help.
With enough support to actually fix the packages, tonight I looked into PAM, which I knew would become troublesome, since I already tried removing NIS support from it a few years ago; at the time I was unable to follow through with upstream because it was still the time I was getting in and out of hospitals.
At the time I had a patch that allowed building if NIS was unavailable, but it didn’t make it possible to disable NIS when available; this is instead implemented now in version 1.1.3-r1, with the nis USE flag, which I suggest to keep disabled (it is disabled by default). When actually enabling it, it’ll require either libtirpc (preferred) or an old glibc version.
Since NIS/YP is a virtually dead technology, it shouldn’t surprise that the default is now to keep it disabled, it’s not just a matter of requiring an extra dependency; I doubt anybody is using that stuff on any modern system; definitely not on users’ desktops or servers, which would be probably happy to drop a bunch of code that was left unused.
For those who wonder how much code are we talking about, comparing the before and after of the pam_unix module, which is the main consumer of the NIS/YP interfaces, it shows the total size decreasing of about 3KiB, one of which is purely part of the executable code, while the rest is distributed across data and rodata sections (which seem to mostly relate to string literals), and the overhead (imported symbol and string tables). Might not sound like a lot, especially on a module with about 50KiB of copy-on-write bss section, but it’s still something you gain by simply removing unused code, without even the need to optimize anything.