= Proposed Self Contained Change: GLIBC 2.18 = https://fedoraproject.org/wiki/Changes/GLIBC218
Change owner(s): Carlos O'Donell carlos@redhat.com
Switch GLIBC in Fedora 20 to GLIBC version 2.18.
== Detailed description == GLIBC 2.18 will be released at the end of July 2013; we have started closely tracking the GLIBC 2.18 development code in Fedora Rawhide and are addressing any issues as they arise. There should be little difference from the users perspective between GLIBC 2.17 used in F19 and GLIBC 2.18 used in F20.
== Scope == Proposal owners: Update glibc to 2.18 from tested upstream release. Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)
The library is backwards compatible with the version of glibc that was shipped in Fedora 19. All packages do not need to be rebuilt.
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.
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.
-Toshio
----- Original Message -----
From: "Toshio Kuratomi" a.badger@gmail.com To: "For participants of the Documentation Project" docs@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" ?
-Toshio
-- docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
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@gmail.com To: "For participants of the Documentation Project" docs@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
----- Original Message -----
On 2013-07-08 7:52, Jaroslav Reznik wrote:
= Proposed Self Contained Change: GLIBC 2.18 =
?!
Ops, let's get this discussion back to devel. I was asked by docs guys to CC them due to release notes, but it seems it does not work this way as it's easy to reply to the wrong mailing list.
Sorry for confusion.
Jaroslav
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs