Re: [PATCH resend] perl/Makefile.PL: teach makefiles about possible old Error.pm files

Chris Frey [off-list ref] writes:

If a previous version of git was installed on a system without a
proper Error.pm, git will install its own.  But the next time
git is compiled on that system, that Error.pm will prevent git from
installing its own copy the second time.  This causes a broken
git install on such systems.

This patch fixes this bug by tagging git's Error.pm with an
INSTALLED_BY flag, and checking for it during the compile.

I think this is a wrong direction to go.

We do not currently deal with broken installations, and "stow" is just one
easy way to install and keep a stale version.  The right solution would be
to check if "Error.pm" we find on the system (be it installed by previous
incarnation of git or some other packages) works as expected, and refrain
from using it if it doesn't.

When the system has a slightly older version of Error.pm, it does not
really matter if that old one case from our own Error.pm (because back
then the system did not have Error.pm at all), or the user installed a
slightly older version of Error.pm from elsewhere.

IOW, I won't be interested in a solution that adds INSTALLED_BY.  Even if
it is ours, as long as it is fresh enough, there is no reason to replace
it with a new copy.  Even if it is _not_ ours, if it is stale and does not
work as we expect, we might have to install our own on our path.

On Wed, May 21, 2008 at 03:51:40PM -0700, Junio C Hamano wrote:

I think this is a wrong direction to go.

We do not currently deal with broken installations, and "stow" is just one
easy way to install and keep a stale version.  The right solution would be
to check if "Error.pm" we find on the system (be it installed by previous
incarnation of git or some other packages) works as expected, and refrain
from using it if it doesn't.

Thank you for your response.

The problem as I see it, is that the decision about whether the existing
Error.pm "works as expected" is done at compile time.  And git will break
itself by repeated installs.

Is it really valid to expect users to uninstall their current version of
git before they can compile a new one correctly?  For systems without
a working Error.pm, this is currently how git behaves.

- Chris

Hi,

On Wed, 21 May 2008, Chris Frey wrote:

The problem as I see it, is that the decision about whether the existing 
Error.pm "works as expected" is done at compile time.  And git will 
break itself by repeated installs.

I do not see how it is _Git_ that breaks itself by repeated installs.  It 
detects that there is an Error.pm.  Fine.  You _remove_ it while 
installing Git.  Not fine.  Not Git's error.

Ciao,
Dscho

On Thu, May 22, 2008 at 12:46:12PM +0100, Johannes Schindelin wrote:

I do not see how it is _Git_ that breaks itself by repeated installs.  It 
detects that there is an Error.pm.  Fine.  You _remove_ it while 
installing Git.  Not fine.  Not Git's error.

I guess I take the view that anything _installed_ by git is a part of git.
If git installs Error.pm, it can't expect the user to keep it around
if he uninstalls that version of git.

The user can do the following, and not have any warning that he'll be
bitten, and won't know what he did wrong.  In fact, when I first saw this
error, I thought it was a bug that was fixed in a point release.

	(slightly abbreviated for clarity, version numbers arbitrary)

	tar xjf git-1.5.4.3.tar.bz2
	cd git...  && ./configure --prefix=/usr/local/stow/git-1.5.4.3
	make && make install
	stow git-1.5.4.3

	tar xjf git-1.5.4.4.tar.bz2
	cd git... && ./configure --prefix=/usr/local/stow/git-1.5.4.4
	make	# git is built assuming git-1.5.4.3 will always exist
	make install

	stow -D git-1.5.4.3
	stow git-1.5.4.4

The user now has a broken git, and has no idea why.  I don't consider the
above to be unusual or user error.

- Chris