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
Attachment:
pgpspw4DjmwIf.pgp
Description: PGP signature
-- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
