Re: Review D38047 ... and then there was one....
- In reply to: Mark Johnston : "Re: Review D38047 ... and then there was one...."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 12 Oct 2024 17:32:23 UTC
On 10/12/24 11:46, Mark Johnston wrote: > > Even if the whole patch is applied atomically, it affects multiple > binaries in the system (at least libc.so and nscd), and there's nothing > guaranteeing that the update is somehow applied atomically across the > whole system. What if some applications using an older libc end up > still running with an updated nscd? That's an untested configuration, > but it might still arise if the whole patch is committed as one unit. Oops, I forgot to address that point. Yes. But I am not sure how to "fix" that. But OLD libc with NEW nscd won't be an issue; nscd only responds to what it is given, and this won't be changing any returns of existing types. NEW libc with OLD nscd could be catastrophic however, even with agent code disabled, since new libc will try to store getgroupmembership() (via lt_pivot and the marshalling and unmarshalling functions) into nscd which just will not understand. I haven't even attempted to test this to even know what will go boom. Put nscd in with the new handling and then wait an entire release cycle? That seems excessive, and even then won't guarantee anything, someone can go right from 14.0 to 14.2 or 14.0 to 15.0, etc. Given the (not) bug reported earlier with pipe limits I don't think it is an unreasonable stand to say that libc goes with the world, you cannot just upgrade libc and not /bin and /usr/bin and expect that to work in all cases. Certainly the documented process is for buildworld/buildkernel/installkernel/installworld.