----- Original Message ----- > On 07/10/2013 08:00 PM, Toshio Kuratomi wrote: > > > > Oops as noted by jreznik, this thread took a brief detour onto the docs > > list > > by mistake. > > > > On Wed, Jul 10, 2013 at 11:47:30AM -0400, Robyn Bergeron wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Toshio Kuratomi" <a.badger@xxxxxxxxx> > >>> To: "For participants of the Documentation Project" > >>> <docs@xxxxxxxxxxxxxxxxxxxxxxx> > >>> Sent: Wednesday, July 10, 2013 8:37:10 AM > >>> Subject: Re: F20 Self Contained Change: GLIBC 2.18 > >>> > >>> On Tue, Jul 09, 2013 at 04:14:22PM -0700, Adam Williamson wrote: > >>>> On 2013-07-08 7:52, Jaroslav Reznik wrote: > >>>>> = Proposed Self Contained Change: GLIBC 2.18 = > >>>> > >>>> ?! > >>>> > >>>> A bump of glibc seems like virtually the definition of a system-wide > >>>> change. Sure, it's _intended_ to be transparently compatible with > >>>> 2.17, but we've seen how that goes before. > >>>> > >>> +1 > >>> > >>> For most libraries I think that an api-compatible version bump wouldn't > >>> need > >>> to even go through the Planning process. But some things, like glibc, > >>> are > >>> depended upon by so many other things that they need to be system-wide > >>> changes so that people can be on the lookout for unexpected problems that > >>> it > >>> might cause. > >> > >> Is it just a matter of "requires a mass rebuild of some sort? If yes, then > >> $X; if no, then $Y" ? > >> > > For most libraries, that's probably a good rule of thumb. I can think of > > some caveats to the rule of thumb though: > > > > * Libraries can also refer to scripting languages' modules which might not > > need a mass rebuild. > > * Changes may not change the API/ABI or SONAME of elf libraries so they > > don't > > need a mass rebuild but they still might require testing or coordination > > across many packages. > > ** The setuptools update: > > https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7 > > Is an example of both of those caveats -- it's a scripting language and > > the changes are not supposed to change API. But the update is an > > upstream > > rewrite of a large amount of the codebase and the package is used by > > a large number of other packages in Fedora. So testing and > > communication > > of the change is the reason for the System-wide-change designation. > > > > glibc, I think, is an extreme example of the second caveat. glibc has an > > effect on close to everything in the distirbution. Upstream rebases should > > probably always be treated as system-wide changes so that other packagers > > can watch out for bugs or changes in behaviour that might be due to glibc > > rather than their own package's code. > > > > -Toshio > > > > > > > I agree. Glibc should be system-wide change, because changes there might > touch many packages. Carlos, could you please change the category to the System Wide one and provide more required details as some FESCo members raised concerns about GLIBC Change being Self Contained. Thanks. Jaroslav > > Marcela > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
