BEWARE: a problematic glibc made it to stable (F16)

Josh Boyer jwboyer at gmail.com
Thu Oct 20 00:35:09 UTC 2011


On Wed, Oct 19, 2011 at 5:51 PM, Rahul Sundaram <metherid at gmail.com> wrote:
> On 10/20/2011 01:06 AM, Adam Williamson wrote:
>> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>>
>>> What did you downgrade to ?
>>> AFAIK Several people had to downgrade from -11 because of nsswitch
>>> issues ... seem glibc is not in good shape :-(
>>
>> You get to pick your breakage. If glibc maintainers would kindly stop
>> pulling random git snapshots into a pending stable release that would be
>> nice
>
> It is horrendously stupid to do this.  It is not a question of being
> kind or nice.  Fedora is not glibc's development platform.  They should
> get their own and stop mucking around and breaking things unnecessarily
> and repeatedly.  If they won't stop on their own, FESCo must push them
> to stop.

Except that Fedora _has_ been glibc's development platform for as long
as I can remember.  The Fedora project might not think so, but it's
exactly what upstream glibc does.  They've made claims that they won't
change things in glibc that depend on external items until it's in a
Fedora release and they do their final upstream release just before
Fedora does (much the chagrin of rel-eng since we've had to take a
late "upstream" release that is essentially a rename after freeze).

There are 3 possible solutions.  I'll list them in what I think is
order of preference.

1) Upstream changes their development model to follow the Fedora
Branched method, introducing a development freeze upstream around the
same time we branch.  Non-trivial rewrites and/or features go into
rawhide, bugfixes go into branched.

2) We ignore this still, and generally realize that yes the practice
is somewhat dubious but for the most part a vastly large and
insurmountable problem.  Karma and testing have worked fairly well
thus far.

3) We have a project hissy fit, stop accepting updates to the glibc
package regardless of what upstream does based on a FESCo/FPC/Board
edict.  We eventually have a non-upstream glibc package maintainer
that does all the work from item #1 while trying to not be at complete
odds with upstream glibc.

I'd vote for #1, but that's a much longer conversation that should be
had upstream and before we even get close to bringing it to FESCo.

josh


More information about the devel mailing list