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.bad...@gmail.com>
To: "For participants of the Documentation Project"
<d...@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
I agree. Glibc should be system-wide change, because changes there might
touch many packages.
Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
