The GNU C Library will be rebased in F21 to match glibc 2.20.

Siddhesh Poyarekar siddhesh at redhat.com
Thu Jul 31 03:12:33 UTC 2014


On Wed, Jul 30, 2014 at 03:36:34PM -0400, Matthew Miller wrote:
> > > The changes in the rebase should be minor since we've
> > > been tracking master the whole time.
> > I remember a similar process causing problems in Rawhide earlier and Jared
> > Smith talking with the glibc team to ensure that only regular releases hit
> > rawhide.

The problem with that approach is that lots of bugs go unnoticed until
very late in rawhide, resulting in those bugs being caught and fixed
only post-release.  Besides, this process is different in principle
from the earlier one because the earlier process simply cut the latest
master into a Fedora release just days before Fedora went gold.

In the current process the glibc release Fedora gets is decided well
in advance, that is when the Fedora release branch is cut from
rawhide.  Combine that with the fact that glibc upstream freezes weeks
before it releases and you'll see that the glibc release that makes it
into a Fedora release is eventually well tested in rawhide *and* is
not ancient.

> It would be nice if we're careful in staging ABI changes in the glibc master
> into Rawhide so it doesn't break. (Possibly something we can do with
> Taskotron?)

ABI changes are a minor problem with respect to glibc because as a
principle, we don't break ABI.  That is, any ABI breakages that happen
are usually bugs.  We try to ensure that with a basic ABI checker in
the glibc testsuite and in future we'll be looking to enhance our ABI
checking capabilities.  Taskotron (based on a quick read from the
wiki) seems to be a good framework for this.

The bigger problem is bugs that brick your system because unlike
kernel, there is currently no way to simply reboot into an older
known-to-work glibc.  We had one such situation last week and IIRC the
last such situation before that was close to two years ago, so while
it is serious, it is not frequent.

That said, we're also thinking of ways to recover from such botched
updates.

Siddhesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140731/0358053e/attachment.sig>


More information about the devel mailing list