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: Romain Naour <romain dot naour at gmail dot com>
- To: Jonathan Nieder <jrnieder at gmail dot com>, "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- Cc: Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, libc-alpha at sourceware dot org, Paul Eggert <eggert at cs dot ucla dot edu>, Zack Weinberg <zackw at panix dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Joseph Myers <joseph at codesourcery dot com>, "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>, Arjan van de Ven <arjan at linux dot intel dot com>
- Date: Mon, 16 Oct 2017 22:58:16 +0200
- Subject: Re: Glibc stable release process (Glibc 2.26.1)
- Authentication-results: sourceware.org; auth=none
- References: <60f78cac-9cf4-51b1-9ade-21cd09783d96@gmail.com> <12f649be-94e4-eccb-be27-026119b7b431@cs.ucla.edu> <20171012192915.GF8813@altlinux.org> <3b29e10a-193a-8070-c040-2ceec9cc743c@redhat.com> <9e7b3052-2476-b6dc-6cff-6920828f3bbe@gotplt.org> <93677583-dc78-cb29-d9ea-d304e0922619@redhat.com> <20171016155520.GA2862@scaer> <34010cc9-62cb-ad22-1ff8-3c09ea59eee6@redhat.com> <20171016173456.GE2862@scaer> <20171016175216.eudre265j3qfline@aiede.mtv.corp.google.com>
Hi All,
Le 16/10/2017 à 19:52, Jonathan Nieder a écrit :
> Hi,
>
> Yann E. MORIN wrote:
>
>> The problem is not about representation of the version string. It is
>> actually choosing what commit to use. As a downstream, we don't have
>> many options when we need to choose a commit on the maintenance branch
>> [1], i.e. either one of:
>> - use the HEAD of the branch
>> - use any one commit between the tag and the HEAD
>>
>> Let's say we choose HEAD now, and then tomorrow you push 5 new commits.
>> Then the HEAD we choose today will tomorrow be seen just as randomly
>> chosen as any other commit. It will tomorrow not mean much more than
>> if we had clicked on the "I feel lucky" button then.
>
> I don't really follow. Would the same problem exist when choosing
> between 2.26.1, 2.26.2, 2.26.3, etc? Why isn't "use the latest
> version from the branch" always the right answer?
>
>> As a consequence, it is very difficult to express what glibc version is
>> running on a system, because it would only ever report '2.26' (or am I
>> mislead?),
>
> Are you talking about version numbers from the package manager or from
> somewhere else?
Here is the version reported by the libc on an embedded Linux system (i.e not a
Linux distro) without any package manager:
# /lib/libc.so.6
GNU C Library (Buildroot) stable release version 2.26, by Roland McGrath et al.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.2.0.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
So without any help from the build system, we can't say what's the libc version.
This can be ether the official Glibc 2.26 release or the glibc-2.26-58-gf725563.
In the end, git describe is not enough. Making a stable release require updating
verison.h and create a git tag.
Note: See I'm using gcc 7.2.0, not gcc-7_1_0-release-372-g1bd23ca.
Best regards,
Romain
>
> Thanks,
> Jonathan
>