This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: meaning of "Automatic date update in version.in" commits


On Wed, 20 Sep 2017 20:14:24 +0200
Matthias Klose <doko@ubuntu.com> wrote:

> On 20.09.2017 19:23, Petr Ovtchenkov wrote:
> > On Wed, 20 Sep 2017 18:16:45 +0200
> > Andreas Schwab <schwab@linux-m68k.org> wrote:
> > 
> >> On Sep 20 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
> >>
> >>> What is the meaning of "Automatic date update in version.in" commits?
> >>> I mean commits like f625a739e5.
> >>
> >> It is used to name the shared libbfd and libopcodes, since there is no
> >> stable ABI.
> >>
> >>> This commits litter commits tree and create problems for  	
> >>> deterministic, bit-identical and/or verifiable builds.
> >>
> >> Why is that a problem?  The version is fixed for a particular source
> >> snapshot.
> >>
> > 
> > It's looks as a problem indeed:
> >    - garbage in commits
> >    - disorientation, when date present in SONAME
> >        0x000000000000000e (SONAME)             Library soname: [libbfd-2.29.0.20170729.so]
> 
> this is correct, and it's usually set to not include the date for a releases, an
> exception being the 2.29.1 release, but things happen.
> 
> > You see:
> > 
> > git show 3110f4be18a2
> >   commit 3110f4be18a2f3b9fcd9663ed1dd141bbd6ed14f
> >   Author: GDB Administrator <gdbadmin@sourceware.org>
> >   Date:   Wed Sep 20 00:01:01 2017 +0000
> > ...
> > git show f625a739     
> >   commit f625a739e567f0110b2675539b7a0e5d5f67c5dc
> >   Author: GDB Administrator <gdbadmin@sourceware.org>
> >   Date:   Wed Sep 20 00:01:22 2017 +0000
> >  ...
> > git diff 3110f4be18a2 f625a739
> > ...
> > Ooops....
> > 
> > This approch produce ambiguity, but try to conceal it.
> 
> Feel free to limit the bumps to exactly one after another commit.

IMO, it useless too: consider two commits in the same day. Even addition
of short hash of top commit duiring build looks better.

>From info above follow, that "Automatic date update in version.in" give nothing
useful.

From datestamps equality not follow ABI compatibility from one side,
and from datestamps inequality not follow ABI incompatibility from another side.

Is another reason to keep it?


--

   - ptr


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]