This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Glibc stable release process (Glibc 2.26.1)
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Arjan van de Ven <arjan at linux dot intel dot com>, Andreas Schwab <schwab at suse dot de>, Siddhesh Poyarekar <siddhesh at sourceware dot org>
- Cc: "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>, "Andreas K. Huettel" <dilfridge at gentoo dot org>, libc-alpha at sourceware dot org, Zack Weinberg <zackw at panix dot com>, "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Romain Naour <romain dot naour at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Wed, 4 Oct 2017 07:06:17 -0700
- Subject: Re: Glibc stable release process (Glibc 2.26.1)
- Authentication-results: sourceware.org; auth=none
- References: <60f78cac-9cf4-51b1-9ade-21cd09783d96@gmail.com> <CAKCAbMj3ByTofE=WsKV-SXOCWyJYStRKvP3DA9ttiW2hUNZffA@mail.gmail.com> <5c98c67b-52a9-dcff-eda7-0f16b8ab478d@sourceware.org> <2839686.ckfu0BZrXq@porto> <a30cc34e-f71f-8e8a-1b99-1c3c1b798e84@redhat.com> <93d68f19-73a0-d906-ece2-bdc002507ca5@sourceware.org> <20171003111452.57b93728@keller.br.ibm.com> <31ca9f87-52e1-2f87-c471-7a55c2af0db3@sourceware.org> <mvm376z71jf.fsf@suse.de> <ce9c0ae4-f35b-eab2-b1c8-0771a2fd2ab6@linux.intel.com> <3996ee7c-ce53-8e1d-6117-eafd12e2924f@redhat.com>
On 10/04/2017 06:32 AM, Florian Weimer wrote:
> On 10/04/2017 02:52 PM, Arjan van de Ven wrote:
>> On 10/4/2017 1:36 AM, Andreas Schwab wrote:
>>> On Okt 04 2017, Siddhesh Poyarekar <siddhesh@sourceware.org>
>>> wrote:
>>>
>>>> 0. Must not break ABI on that branch
>>>
>>> We must not break the ABI on any branch. What you probably mean
>>> is that we must not extend the ABI on the release branch.
>>
>> and no new symvers
>>
>> I'd expect this to be both backward (like usual) but also forward
>> compatible as a goal.
>>
>> now if a CVE requires a new symver, I'm sure that will trump that
>> rule
>
> No, if a new symbol version is required, we cannot backport the fix.
> We need to leave it unfixed or come up with a different fix.
Agreed. We should not be adding new symbol versions to stable branches.
Likewise as Joseph and Andreas mentioned, we should not be changing
the semantics of GLIBC_PRIVATE symbols, nor adding new ones, they can
and will crash processes as glibc is updated.
--
Cheers,
Carlos.