F20 Self Contained Change: GLIBC 2.18
Toshio Kuratomi
a.badger at gmail.com
Wed Jul 10 18:00:12 UTC 2013
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/docs/attachments/20130710/4162745e/attachment.sig>
More information about the docs
mailing list