Re: [announce] skarnet.org Summer 2018 release
Oh. That's kind of drastic. I re-read the documentation of nsss and utmps, in case I missed it the first time, and still think none of it suggests that this is the intended behaviour. You're right, the documentation should mention that libc header files will be replaced. I'll add something. -- Laurent
Re: [announce] skarnet.org Summer 2018 release
2018-08-21 2:29 GMT-03:00 Laurent Bercot: >> >> 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. Oh. That's kind of drastic. I re-read the documentation of nsss and utmps, in case I missed it the first time, and still think none of it suggests that this is the intended behaviour. The system consistency argument is a good one, though, and getting these packages to install in parallel with libc headers is doable at packaging time, so OK I guess. But I think that more explicitly warning that 'make install' will likely overwrite libc files with the 'configure' script's defaults would be better. > The exact same pattern happens with utmps, which replaces the > libc's header, and you didn't seem to have a problem > with it at the time. :) That's because I didn't notice :P I wanted to see what the effect of --enable-nsss was on packages of the s6 stack, found surprising that it didn't affect the C code, not even #include directives, looked at the 'configure' script, found that it didn't add -I options either, wondered how could that possibly work, and finally realized where the nsss headers were installed by default. Thanks, G.
Re: [announce] skarnet.org Summer 2018 release
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 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 , and
headers with the nsss ones, the same way it replaces the
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
Re: [announce] skarnet.org Summer 2018 release
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 , or with no regard to
implementation) and for applications that deliberately want libnsss
(e.g. that explicitly include, say, ). 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.
