So I guess it's time to get rid of the examples that use them in the s6-rc package (examples/source/mdevd{,-listener})? And to modify examples/source/init-coldplug if this means getting rid of BusyBox mdev?
Ah, those pesky examples/ subdirs. I always forget to check them. Will fix, yes. Thanks for the report.
...and now that I looked again at the s6-rc examples, I noticed that longruns that are members of pipelines haven't been adapted to the 0.4.x.x format: pipeline-name files are still in the definition directories of the producers.
Will fix too. >.>
The actions of its build system look problematic. The package contains replacements for pwd.h, grp.h and shadow.h, these are necessary to define getpwnam(), getgrnam(), getspnam(), etc. as macros that expand to the name of the nsss_*() function chosen by the NSSS_DISABLE_* settings, and the makefile installs them directly in the specified includedir (./configure --includedir=DIR), correct? Say this is the compiler's 'standard' headers directory (i.e. normally /usr/include). Then, it is likely also the location of the files of the same name supplied by the libc, and in that case, 'make install' would overwrite them. Or, if the directory is handled by a package manager and files are 'owned' by packages, this would result in file collisions or similar.
That's normal and expected. Those files provide libc functionality, so they're meant to replace libc files if installed into /usr/include. If a system needs to keep the original libc headers, it needs to install nsss into a different directory, and nsss-aware applications will then need to be built using -I switches, while non-nsss-aware applications won't need to change anything at all. The exact same pattern happens with utmps, which replaces the libc's <utmpx.h> header, and you didn't seem to have a problem with it at the time. :) For system consistency, generally, all applications should either be or not be using nsss. If behaviour varies from one application to the next, it can quickly become confusing to the user. It is a distribution's job to decide what policy it wants to implement. Does it want to use nsss everywhere or not? If yes, it should be prepared to replace the <pwd.h>, <grp.h> and <shadow.h> headers with the nsss ones, the same way it replaces the <utmpx.h> header with the utmps one. If not, it probably should not install nsss at all. If wishy-washy, it should install nsss into its own place (slashpackage is great for that) and then deal with the search paths as with any other package.
Can't src/include/pwd.h get merged with src/include/nsss/pwd.h in a single file, adjusting #include directives where (if?) needed, and installed in $includedir/nsss?
No, because these files don't have the same purpose at all. The nsss/*.h files are meant to be used by applications that are what you call nsss-aware, i.e. explicitly using nsss primitives, and that will do so whether or not nsss is installed in the "standard" location or not - just like applications using skalibs/*.h includes for instance. nsss/*.h files are regular "opt-in" headers. The pwd.h, grp.h and shadow.h files are meant to provide an implementation of the POSIX layer; their audience is "nsss-unaware" software. If they're installed into the "standard" place, most likely /usr/include, then nsss-unaware applications are automatically using nsss, which is the whole point. Bottom line: if you make the decision to switch an entire system to nsss, install the headers in the standard place and adjust your package manager settings so that pwd.h, grp.h and shadow.h are owned by the nsss-dev package instead of the libc-dev package, just like utmpx.h is owned by the utmps-dev package. If you make the decision to keep nsss optional, install it in a place where its headers won't overwrite the libc's. I did not add automatic addincpath adjustment to --enable-nsss because it would simply have duplicated the work of --with-include and --with-lib. If a system has totally switched to nsss, then --enable-nsss is the only flag you need for skaware. If a system has nsss installed in a non-default location, then you need --with-include/--with-lib flags as you would with any other package installed in a non-default location. Hope this clears things up a bit. -- Laurent