Remove INSTALL file from Git

[df7cb]

The autoconf toolchain really likes to replace INSTALL with its own generic installation instructions, causing noise in the git diff output. Since the current file doesn't really have content, just remove it and add INSTALL to .gitignore.

This has been driving me crazy ever since Debian started automatic autoreconf'ing during package builds.

Plain autoreconf -i doesn't trigger it, but I do run into it all the time... please consider accepting this.

[airween]

I'm fine with this, but we can consider to add a build.sh script which runs all necessary auto* commands, something like this:

rm -rf autom4te.cache
rm -f aclocal.m4

case `uname` in Darwin*) glibtoolize --force --copy ;;
  *) libtoolize --force --copy ;; esac

autoreconf --install
autoheader
automake --add-missing --foreign --copy --force-missing
autoconf --force
rm -rf autom4te.cache

[df7cb]

Afaict, autoreconf -i should be enough, so making a shell script for it might be overkill.

That's also what's documented in README (perhaps in a weird order, though).

[N0NB]

If INSTALL doesn't exist, then one of the Autotools will complain, as I recall as having it is a requirement of the GNU standard, if that matters to anyone.

Christoph, do you have the same issue with Hamlib and its INSTALL file?

[df7cb]

autoreconf -i puts the boilerplate INSTALL file in place, then everything is happy.

I have not noticed the problem in hamlib, not sure what's different there.

[dl1jbe]

Can you please give some more information under which circumstances the INSTALL file will be replaced?

Best would be the chain of commands which leads to the problem. I would like to reproduce and see where it comes from?. Thanks.

[N0NB]

autoreconf -i puts the boilerplate INSTALL file in place, then everything is happy.

I have not noticed the problem in hamlib, not sure what's different there.

Could it be related to size of the file?

All Hamlib's bootstrap does is check that the three main Autotools executable files are available along with pkg-config and then runs autoreconf -i.

I seem to recall that the lack of INSTALL will cause make distcheck to complain of fail as this is a required file per the GNU packaging standard (not that we're required to strictly adhere to it).

[zcsahok]

I guess this is the issue -- on a fresh clone

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ autoreconf --install --force
configure.ac:17: installing './compile'
configure.ac:48: installing './config.guess'
configure.ac:48: installing './config.sub'
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   INSTALL

no changes added to commit (use "git add" and/or "git commit -a")

$ git diff
diff --git a/INSTALL b/INSTALL
index cd9fb18..d3b6e4e 100644
--- a/INSTALL
+++ b/INSTALL
@@ -1,3 +1,365 @@
-INSTALL
+Installation Instructions
+*************************
 
-Please see README.md for installation instructions.
\ No newline at end of file
+Basic Installation
+==================
+
+   The following shell commands:
...

[dl1jbe]

I see. And why do we need to do an

$ autoreconf --install --force

instead of an

$ autoreconf --install

which would be enough?

Man page states explicitly that '-f' means do 'consider all files obsolete' and therefore replace them by new ones - even if not needed.

[zcsahok]

I don't recall why I added --force to my local build script. Maybe it was needed when adding test files, not sure. A normal build in fact works fine with just --install, as described in README.md. If INSTALL would add extra information regarding installation, then I'd suggest renaming it to INSTALL.md. As it does not, I could live without it. (in my build script I use git checkout INSTALL to get back the original file, so never had to bother with it)

[dl1jbe]

I don't recall why I added --force to my local build script. Maybe it was needed when adding test files, not sure.

Hmm. For adding test files a 'autoreconf -i ' should normally enough. But anyway, we now know where the problem comes from.

If INSTALL would add extra information regarding installation, then I'd suggest renaming it to INSTALL.md. As it does not, I could live without it. (in my build script I use git checkout INSTALL to get back the original file, so never had to bother with it)

Moving it to INSTALL.md would conflict with the GNU standard Nate mentioned before. Any run of 'make distcheck' before release would fail.

But I think at the moment we should leave it as it is. Maybe time to redraw the PR?

[N0NB]

Another option is to add a bootsrap script (borrow the one from Hamlib!) that simply checks for the presence of Autoconf and Automake and then runs autoreconf -i.

I wonder if the Debian tooling, in the absence of a bootstrap[.sh] or autogen[.sh] (the less preferred name), simply runs autoreconf --install --force as a means to make packages that comply with the GNU packaging standard and thus lessen the number of packaging bugs generated. There are probably a number of upstream packages that lack all the requisite files.

[df7cb]

Debian is not using any bootstrap/autogen shell scripts but calling autoreconf -f -i directly: https://sources.debian.org/src/dh-autoreconf/21/dh_autoreconf#L181

TBH I think adding such a shell script doesn't fix anything. People who know how to use autoconf will use autoreconf with options, and everyone else will have to read the README which already says to use autoreconf --install.

For the original request, I still think removing the INSTALL file from git is the right fix as @zcsahok's diff shows.