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

Peter Robinson pbrobinson at gmail.com
Thu Jul 31 13:13:44 UTC 2014


On Wed, Jul 30, 2014 at 8:36 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Wed, Jul 30, 2014 at 03:16:30PM -0400, Rahul Sundaram wrote:
>> > * Rawhide tracks glibc master.
>> > * Fedora release is branched from Rawhide.
>> > * glibc release is made upstream.
>> > * Fedora branch is rebased on glibc upstream release
>> >   to include ABI guarantees.
>> > * Fedora release goes GA.
>> > 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.
>
> 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?)

Ultimately glibc as a core library should be following what the rest
of the packages / features in development change process are required
to do IE anything that might change the ABI should have landed before
the mass rebuild so it can be addressed as part of that and hence be
in a stable state at the same time as the other features are due to be
complete.

The fact that a core library that's stability is critical to the
distribution as a whole doesn't bother to adhere to this and while
having gone through the hoops of putting in a feature change basically
then proceeded to completely ignore the requirements of said process
(ie they dumped a bunch of stuff on the wiki and haven't bothered to
revisit it and update it since) is some what pathetic in my mind.

What happens if between now and when 2.20 goes GA there's a
requirement of an ABI break and we need to rebuild a chuck of the
distribution? It doesn't affect them as they don't need to do the work
to make that happen.

Peter


More information about the devel mailing list