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]

Re: 2.25 freeze - a little more than the holiday fortnight to go


On 12/22/2016 02:30 PM, Torvald Riegel wrote:

Note that I'm *not* saying we need to fix this in glibc through a compat
symbol or with the help of flags.  We just need to offer *any* solution
whatsoever.

So what do you think this means for accepting the new condvar in 2.25?
Is having "something" a blocker for the condvar?  I would like to not
set the precedent that single buggy programs can affect glibc's
development; the emacs case was unfortunate enough.

It's definitely a bug Fedora (as a distribution) must solve before releasing a new version which is based on a glibc which has the new condvar. It may affect other distributions using RPM. The same issue affects self-compiled applications using Berkeley DB.

If someone could write an external tool which massages a dormant Berkeley DB environment (i.e., one that hasn't been opened by an application) so that it is compatible with the new condvar, and integrate that seamlessly into the Fedora update process to patch the RPM database, that would be a perfectly fine solution from my point of view. (Bonus points if the tool can be run against arbitrary Berkeley DB environments, not just the RPM database.)

I'm pretty confident that such a tool could be written, but until we have demonstrated that it can be integrated into the Fedora update process, there is a risk that the new condvar implementation, as it exists today, is technically *impossible* to release as an in-place Fedora update. (Some of the manual recovery steps can lead to unrecoverable data loss, unfortunately, so Fedora as a distribution really does not have much choice here and must find a technical, automated solution. A release note will not be good enough.)

Of course, this is not your problem, and not the problem of glibc upstream project. But it could well affected important glibc users. It is definitely a problem for Fedora, and something Fedora and Red Hat have to solve. And based on my experience, assistance from the toolchain team in this matter will be expected. 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.

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.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]