This is the mail archive of the 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]

Re: configuring /var/run with newer autoconf

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

> 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]