git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Chris Frey <cdfrey@foursquare.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH resend] perl/Makefile.PL: teach makefiles about possible old Error.pm files
Date: Wed, 21 May 2008 15:51:40 -0700	[thread overview]
Message-ID: <7vzlqjz2wz.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080521222150.GA29696@foursquare.net> (Chris Frey's message of "Wed, 21 May 2008 18:21:50 -0400")

Chris Frey <cdfrey@foursquare.net> 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.

  reply	other threads:[~2008-05-21 22:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-17  1:16 [PATCH] perl/Makefile.PL: teach makefiles about possible old Error.pm files Chris Frey
2008-05-17  1:25 ` Chris Frey
2008-05-21 22:21 ` [PATCH resend] " Chris Frey
2008-05-21 22:51   ` Junio C Hamano [this message]
2008-05-21 23:56     ` Chris Frey
2008-05-22 11:46       ` Johannes Schindelin
2008-05-22 16:43         ` Chris Frey
2008-05-22 17:26           ` Junio C Hamano
2008-05-22 18:12             ` Chris Frey
2008-05-23 19:22               ` [PATCH] INSTALL: explain Error.pm dependency Chris Frey
2008-05-22 21:56             ` [PATCH resend] perl/Makefile.PL: teach makefiles about possible old Error.pm files Sverre Rabbelier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vzlqjz2wz.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=cdfrey@foursquare.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).