https://sourceware.org/bugzilla/show_bug.cgi?id=31881
Bug ID: 31881
Summary: binutils-gdb Git repository is flooded by automatic
commits
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: admin
Assignee: unassigned at sourceware dot org
Reporter: rostiprodev at gmail dot com
Target Milestone: ---
There are many daily automatic commits that continuously change one single line
with definition of the BFD_VERSION_DATE in the bfd/version.h file. There are
also many daily automatic commits with a similar change in the gdb/version.in
file (in a past, probably before the GDB repository was merged with the
Binutils repository). Maybe there are/were other such daily automatic commits
that I just missed. All these automatic commits flooded the binutils-gdb Git
repository and made it hard to follow the commit history. Also the Git
repository itself is too big now (993MB) and going to be even bigger just
because of such automatic commits. Each such commit makes at least three new
objects in Git repository: new BLOB object, new TREE object and new COMMIT
object.
Let's make some math. Right now there are 146243 commits in all branches. In
all those commits there are 11117 automatic daily commits of bfd/version.h and
9149 automatic daily commits of gdb/version.in, i.e. about 13.86% of all
commits of all times are those automatic daily commits and this is too much!
The bfd/version.h file has the following explanation:
/* The date below is automatically updated every day by a bot. During
development, we include the date in the tools' version strings
(visible in 'ld -v' etc.) because people build binutils from a
variety of sources - git, tarballs, distro sources - and we want
something that can easily identify the source they used when they
report bugs. The bfd version plus date is usually good enough for
that purpose.
During development, this date ends up in libbfd and libopcodes
sonames because people naturally expect shared libraries with the
same soname to have compatible ABIs. We could bump the bfd version
on every ABI change, but that's just another thing contributors and
maintainers would need to remember. Instead, it's much easier for
all if the soname contains the date. This is not perfect but is
good enough.
In releases, the date is not included in either version strings or
sonames. */
Let's check the "variety of sources": distro sources, tarballs and git.
I use Fedora 40 and it seems like it has release versions of Binutils and GDB,
because I don't see the BFD_VERSION_DATE value in neither version string nor
sonames:
$ ld -v
GNU ld version 2.41-37.fc40
$ gdb --version | head -n 1
GNU gdb (Fedora Linux) 14.2-2.fc40
$ ls -l libopcodes* libbfd*
-rwxr-xr-x. 1 root root 1292336 May 3 03:00 libbfd-2.41-37.fc40.so
-rwxr-xr-x. 1 root root 882512 May 3 03:00 libopcodes-2.41-37.fc40.so
I think the majority of other Linux distributions use release versions of
Binutils and of GDB or locally patched release versions as well as Fedora. Even
LFS instructs their users to build binutils and GDB from the release tarballs.
So the "distro sources" seems to be not relevant.
The other possibility is tarballs. I doubt anybody makes tarballs manually or
by their own custom script, because there is the src-release.sh script that
makes tarballs of any particular part of the binutils-gdb Git repository. But
this script makes release tarballs, i.e. tarballs that don't use the
BFD_VERSION_DATE in version or sonames, as explained in the bfd/version.h file.
So this possibility is also not relevant.
And the last possibility is Git repository used directly. I think this
possibility is relatively rare, at least outside of the project itself. I think
the the above explanation in the bfd/version.h file is relevant only or mostly
for those who build directly from the Git repository, i.e. developers,
contributors and other enthusiasts.
In case you want to support BFD_VERSION_DATE for those who build from the Git
repository directly the value of the BFD_VERSION_DATE or the whole
bfd/version.h file could be generated by the by the "configure" script
according to the last commit. Generating the whole bfd/version.h file and not
saving it in Git repo could be even better because otherwise there will be
uncommitted change of tracked file. You can also save that value in the UNIX
time format instead, i.e. more precisely. You can also use something like
BFD_VERSION_HASH instead or additionally and put the hash of the last commit
there.
Please consider a fix like the above.
--
You are receiving this mail because:
You are on the CC list for the bug.
