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(a)gmail.com>
> To: "For participants of the Documentation Project"
<docs(a)lists.fedoraproject.org>
> 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