This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze - a little more than the holiday fortnight to go
On Thu, 2016-12-22 at 14:59 +0100, Florian Weimer wrote:
> there is a risk that the new condvar implementation, as it
> exists today, is technically *impossible* to release as an in-place
> Fedora update.
This would be bad for the practice of deploying glibc updates, I agree
with that. However, not having a complete solution for that other
problem should not delay our testing of the new condvar. We can always
revert the condvar closer to the 2.25 release.
> If we merge the new
> condvar as it exists today, and the tool cannot be written after all,
> then we'll have to maintain a suitably patched condvar fork in Fedora
> (and we'd likely need your help with that). Other distributions which
> have encountered a similar problem will have to maintain a similar fork.
Or they would have to use an older or forked glibc for the affected
buggy program only.
Also, if such a tool cannot be written ever, then we're in a very bad
situation too because all users of condvars will have a slightly broken
condvar (because of the bug in the old condvar algorithm). This might
even affect bdb too!
> With Emacs, we delayed changing malloc until we were sure we found an
> approach which kept existing Emacs binaries working. Similarly, we can
> make the condvar change in Fedora as long as it does not break in-place
> upgrades.
The difference is that the glibc change affecting Emacs was an
enhancement, not a bug fix. The current condvar is not conforming to
POSIX. Delaying bug fixes for everyone is bad.