Re: [announce] skarnet.org Summer 2018 release

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Tue, 21 Aug 2018 22:33:31 -0300

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 <utmpx.h> 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.
Received on Wed Aug 22 2018 - 01:33:31 UTC