Arch Linux

https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=NEWS;h=5162534d2d667afa58b2d4831fd695762700d4a8;hp=9efe1e5c0eb0cdfe46e292b3b5691bb3276ddc15;hb=1e4d83f6fe38613e6f209ff09dfad8e69a6e1629;hpb=76b2c32a166f4812c0649162c9df99d707779304
* The NIS(+) name service modules, libnss_nis, libnss_nisplus, and
libnss_compat, are deprecated, and will not be built or installed by
default. Replacement implementations based on TIRPC, which
additionally support IPv6, are available from
<https://github.com/thkukuk/libnss_{compat,nis,nisplus}>.

* The NIS(+) support library, libnsl, is deprecated. By default, a
compatibility shared library will be built and installed, but not
headers or development libraries.

Only a few NIS-related programs require this library.
A replacement implementation based on TIRPC is available from
<https://github.com/thkukuk/libnsl>. Like the replacement NIS(+)
name service modules, the replacement supports IPv6, and it can be
coinstalled with the compatibility shared library from glibc.

* New configure option --enable-obsolete-nsl will cause libnsl's
headers, and the NIS(+) name service modules, to be built and
installed. This option may be removed in a future release.

So perhaps package https://github.com/thkukuk/libnss_compat and https://github.com/thkukuk/libnsl instead of using --enable-obsolete-nsl

Or we could just switch to the files module and not care about NIS support. The only thing the compat module adds to passwd/group/shadow is that you can import NIS users and groups using special syntax, other than that it works the same as the files module.

If--enable-obsolete-nsl is not used it might be appropriate to review the use of --enable-obsolete-rpc which could be provided by https://github.com/thkukuk/rpcsvc-proto

Bartłomiej added enable-obsolete-nsl in glibc 2.26. Everything is fine in testing.

Is this a valid long-term plan, or will we have to implement something like Johannes's proposition eventually?

No, it was my lazy plan. I plan to drop it in some pkgrel bump.

Since nsswitch.conf is a backup file for filesystem, wouldn't dropping the obsolete-nsl flag require a manual intervention for everyone with a modified nsswitch.conf? As I understand it now, breaking the 'compat' module would force all such users to correct it *before* they update to a new glibc, or they will become immediately unable to fix their system without booting from alternative media or using an emergency shell.

Jeb, this is correct. I have been running glibc-2.26 for the last three weeks and found out the hard way that manual intervention was required.

I cannot think of any "tidy" solution that requires no manual intervention, but what about shipping a new nsswitch.conf, posting a news item, and riding the compat module for a few months to let the slowest of users merge the pacnew.

EDIT: Scratch that, I already had a modified/unmerged nsswitch.conf at the time of my upgrade to 2.26.

For the record, the switch from host to compat was asked in  FS#51709 .

If we plan to remove it from glibc, I will push an update of the filesystem package soon.

When you drop the --enable-obsolete-nsl can you please also remove the compatibility library as well so that a package wanting to supply libnsl will not conflict.

Now in trunk. A test package is available here: http://pkgbuild.com/~seblu/filesystem-2017.08-0.3-x86_64.pkg.tar.xz.

filesystem-2017.08-0.3 works fine here. But I am still running glib with the compat library.