Re: GNUmakefile and 'make install'

[Eric Blake]

Bruno Haible <bruno <at> clisp.org> writes:

> 
> Eric Blake wrote:
> > I still stand by the claim that making 'make install' error out on 
> > version mismatch will only affect people trying to install an unreleased 
> > development snapshot who have changed the VCS tree since the last time they 
ran 
> > a full autoreconf.
> 
> It just feels wrong to me. It punishes your most loyal contributors: the
> developers who want to test this or that modification and do a "make install"
> for full-scale testing.

Actually, I see it as helping them - it is our way of saying 'you are about to 
install something with a beta version number; but we have detected that your 
installed version number won't match what you actually have checked out, so go 
back and fix that first'.  There have already been reports about people 
complaining that AC_PREREQ([2.61.100]) (in use at one point in m4.git master 
branch configure.ac) didn't work for them, because they had done a 'git pull' 
to get a new enough autoconf, then run 'make install', but ended up installing 
something that was still labeled 2.61.80, so even though they  had a new enough 
autoconf.git, m4 did not know it.

> 
> It will also punish the distributors, because nearly every distributor applies
> some patch to some source files. You will force him to rebuild all the
> autoconf/automake generated files, for all packages.

Let me reiterate.  This does NOT force a distributor to rebuild, UNLESS they 
are operating in a VCS directory and do not have a .tarball-version file.  
Modifications made to a tarball OUTSIDE of the VCS tree do not trigger this 
rule, since in that case, git-version-gen favors the existing .tarball-version.

> The basic idea of software freedom is to allow any user/developer to make
> modifications, the same way as the package maintainer does modifications. By
> saying "unmodified versions install fine, modified copies give an error" you
> are effectively treating users worse than you treat yourself. You then don't
> need to wonder if less people contribute modifications.

We are stating that 'incompletely modified files' have problems installing.  If 
you modify correctly, you will not run into the rejection notice.  It is still 
possible to create a version of autoconf labeled 2.62 (and not 2.62.x) but 
which does not match the tarball on FSF's site; the trick is to use the 
correct .tarball-version and do the patches outside of autoconf.git.

> 
> Can you find other ways of solving the technical problem?

That is the whole point of this thread - we would like to standardize a better 
way to make incremental versions useful without having to recompile the world.  
But until we have such a way, we'd like to let the users know that we are aware 
of the less-than-stellar solution that we currently have, by asking them to 
recompile manually when their incremental version is stale.  I hope that down 
the road, we can remove my GNUmakefile change from today; but in the meantime, 
I think today's change is better than what we had yesterday.

-- 
Eric Blake