This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
It was <2016-04-07 czw 17:14>, when Joseph Myers wrote: > On Thu, 7 Apr 2016, Åukasz Stelmach wrote: > >> Hi, >> >> TL;DR Is there a chance a patch requiring autconf 2.70 is going to be >> accepted? > > I don't think it's appropriate to require unreleased versions of external > packages. I agree. I wrote about 2.70 before finding out it hasn't been released yet. > I'm also doubtful that making the /var/run path configurable is an > appropriate change at all. This path appears in _PATH_VARRUN in > sysdeps/unix/sysv/linux/paths.h, an installed header. And sysdeps/generic/paths.h and nowhere else. OK, I assume it is a part API and changing it can break software compiled with different headers. > In general it's best for installed headers to depend only on the > (architecture, OS) pair (with architecture being interpreted so that > e.g. 32-bit and 64-bit get the same headers), not on other > configuration variants. If there is consensus on /run being the right > path on GNU/Linux, then the change should simply be made > unconditionally (with appropriate documentation in NEWS). All you write is valid. Unfortunately this does not bring me any closer to solving the nscd+automount deadlock. Can you think of any solution that allows: a) configuring /var as mounted via autofs and b) to avoid software lock-ups when programmes unconditionally try to connect to nscd and c) not to disable nscd entirely? Kind regards, -- Åukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |