Hello,
2018-08-14 19:20 GMT-03:00 Laurent Bercot:
>
> * s6-linux-utils-2.5.0.0
> ----------------------
>
> […]
> - s6-devd, s6-uevent-listener and s6-uevent-spawner have been removed.
> They have been obsoleted by mdevd.
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?
> * s6-rc-0.4.1.0
> -------------
...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.
> * nsss-0.0.1.0
> ------------
>
> This is a new package: an alternative implementation of the "name
> service switch" mechanism, i.e. a way for getpwnam() and friends to
> use another backend than the traditional /etc/passwd and similar
> files, without the problems of NSS such as using dynamically loaded
> modules.
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.
So alternatively, one could specify a different includedir. But then,
to build applications so that they link to libnsss, one would have to
always supply an -I (capital i) option to the compiler, naming this
directory. Both for 'nsss-unaware' applications (i.e. applications
that simply include <pwd.h>, <grp.h> or <shadow.h> with no regard to
implementation) and for applications that deliberately want libnsss
(e.g. that explicitly include, say, <nsss/nsss-switch.h>). In the
latter case, because none of the src/include/nsss/*.h files would be
in the 'nsss' subdirectory of the 'standard' headers directory either.
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? And the same with grp.h and shadow.h?
This way, 'nsss-aware' applications don't need compiler -I options if
$includedir is the 'standard' headers directory, and there would be no
file overwriting or collisions. Only nsss-unaware applications would
need an -I$include/nsss option, but they also already need at least an
-lnsss option, i.e they already need administrator intervention to
link them to libnsss anyway. And to avoid having to add --with-include
when --enable-nsss is used, I was thinking that './configure
--enable-nsss' and './configure --enable-nsss=yes' could add '-I
$includedir/nsss' to addincpath, and './configure --enable-nsss=DIR'
could add '-I DIR' to addincpath, Unless combined with
--enable-slashpackage, which recent commits to the packages' Git
repositories seem to have taken care of.
Thanks,
G.
Received on Mon Aug 20 2018 - 18:14:10 UTC