F20 Self Contained Change: GLIBC 2.18

[Toshio Kuratomi]

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 at gmail.com>
> > To: "For participants of the Documentation Project" <docs at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130710/4162745e/attachment.sig>