Обсуждение: Proposed autoconf change: rip out search for 'install'
I just got a note from Chris Williams to the effect that when he built
6.4 on his HPUX setup, the install step failed. Seems that HP has
a largely incompatible program called "install" living in /etc, and
configure tried to use it. (I hadn't ever noticed this because I don't
run with /etc in my path except when I'm root. HP does offer a
compatible flavor of install in /opt/imake/bin...)
This brings up something I've been thinking for a while, but hadn't
gotten around to proposing. I have noticed that most other large
packages that need "install" use an install script distributed
with the package; they all say there's too much variation in
vendor-supplied install programs to risk depending on those.
I say it's time we do the same. We do already include an install script
(src/install-sh), so it's not at all clear what the value is of trying
to use a locally provided install program. We're not saving space, and
we're wasting time during configure.
I propose taking out configure's search for an install program and
just letting it select install-sh always. Anyone who really wanted
to use their local install could still override that decision by
changing Makefile.global.
Another alternative is to use the standard autoconf AC_PROG_INSTALL
macro, which contains some grotty tests to weed out incompatible
versions of install. But I don't really see the reason for taking any
risk.
Comments? Objections?
regards, tom lane
On Mon, 7 Dec 1998, Tom Lane wrote:
> I just got a note from Chris Williams to the effect that when he built
> 6.4 on his HPUX setup, the install step failed. Seems that HP has
> a largely incompatible program called "install" living in /etc, and
> configure tried to use it. (I hadn't ever noticed this because I don't
> run with /etc in my path except when I'm root. HP does offer a
> compatible flavor of install in /opt/imake/bin...)
>
> This brings up something I've been thinking for a while, but hadn't
> gotten around to proposing. I have noticed that most other large
> packages that need "install" use an install script distributed
> with the package; they all say there's too much variation in
> vendor-supplied install programs to risk depending on those.
> I say it's time we do the same. We do already include an install script
> (src/install-sh), so it's not at all clear what the value is of trying
> to use a locally provided install program. We're not saving space, and
> we're wasting time during configure.
>
> I propose taking out configure's search for an install program and
> just letting it select install-sh always. Anyone who really wanted
> to use their local install could still override that decision by
> changing Makefile.global.
>
> Another alternative is to use the standard autoconf AC_PROG_INSTALL
> macro, which contains some grotty tests to weed out incompatible
> versions of install. But I don't really see the reason for taking any
> risk.
>
> Comments? Objections?
AC_PROG_INSTALL looks like a good way to do it...go for it...I do
object to having it 'hardcoded', as it makes the assumption that the
system administrator doesn't know what they are doing (ie. in setting
paths)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I propose taking out configure's search for an install program and > just letting it select install-sh always. Anyone who really wanted > to use their local install could still override that decision by > changing Makefile.global. > > Comments? Objections? I have no problem with that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 7 Dec 1998, Bruce Momjian wrote:
> > I propose taking out configure's search for an install program and
> > just letting it select install-sh always. Anyone who really wanted
> > to use their local install could still override that decision by
> > changing Makefile.global.
>
> >
> > Comments? Objections?
>
> I have no problem with that.
I do...I don't like it when we assume that we're right and the
person installing the software is wrong...usnig AC_PROG_INSTALL should be
sufficient...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
>>>> I propose taking out configure's search for an install program and
>>>> just letting it select install-sh always. Anyone who really wanted
>>>> to use their local install could still override that decision by
>>>> changing Makefile.global.
>> I have no problem with that.
> I do...I don't like it when we assume that we're right and the
> person installing the software is wrong...usnig AC_PROG_INSTALL should be
> sufficient...
Well, not to put too fine a point on it, Chris' complaint was that the
software failed to do the Right Thing even though he had a peculiar
PATH. And certainly we do not have any installation instruction that
cautions you against having an incompatible "install" in your path.
(I'd not want to try to write an instruction like that, either, because
I don't know which ones aren't compatible.) So I'm not convinced by
Marc's argument that the configure program should assume the user knows
what he's doing in this respect.
The minimum-change, safest way to address the issue is to take out
configure.in's search for an install and always use install-sh
unless the user specifically overrides that. Using AC_PROG_INSTALL
looks to me like it introduces more risk; there's a possibility that
it will settle on an install that isn't really compatible, which is
the same problem we've got now. On the other hand, there's a lot to
be said for using standardized solutions, and AC_PROG_INSTALL is
presumably pretty well tested...
regards, tom lane
> I do...I don't like it when we assume that we're right and the
> person installing the software is wrong...usnig AC_PROG_INSTALL should
> be sufficient...
... and if it isn't, then perhaps a bunch of
#ifdef HPUX ...
if (port ~ "HPUX") ...
might make it clearer why we made the choice. All of the platforms have
their foibles, but some brands don't even give it the old college try on
keeping consistancy and standardization between releases and within a
release. I'd always liked Dec machines because even through major
releases and processor revs they managed binary and environment
compatibility. 'Course, fat lot of good it did them *sniff*. HP has
binaries which won't run on different processors in the same line, and
has system inconsistancies even between v9.01 and v9.02! Who do they
think they are, PostgreSQL? :)
Anyway, Tom, do you think that the AC_PROG_INSTALL function might help
on the HP? If so, we've probably stressed it pretty good...
- Tom
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> Anyway, Tom, do you think that the AC_PROG_INSTALL function might help
> on the HP? If so, we've probably stressed it pretty good...
AC_PROG_INSTALL would solve the problem on HP --- one of the ad hoc
tests that it uses is to ignore /etc/install and /usr/sbin/install,
which are the two places that that program might live on HP. (BTW,
AC_PROG_INSTALL's comments refer to this as SysV install, so I think
you are being unfairly hard on HP to blame them for the lack of
compatibility. They *are* being compatible ... with SysV. And
normal users don't put either of those directories into PATH.)
I don't *know* of any cases where AC_PROG_INSTALL would fail, and
certainly it's pretty widely used. I'm just being paranoid because
it has no way to directly test what the install program really does ---
it is using a bunch of ad-hoc rules to guess whether a program it finds
is likely to be BSD-compatible or not. That's not my idea of how a
reliable autoconfiguration test ought to work.
regards, tom lane
On Mon, 7 Dec 1998, Tom Lane wrote:
> I don't *know* of any cases where AC_PROG_INSTALL would fail, and
Then sounds like a good solution to me...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The minimum-change, safest way to address the issue is to take out configure.in's search for an install and always useinstall-sh unless the user specifically overrides that. Using AC_PROG_INSTALL looks to me like it introduces more risk;there's a possibility that it will settle on an install that isn't really compatible, which is the same problem we'vegot now. On the other hand, there's a lot to be said for using standardized solutions, and AC_PROG_INSTALL is presumablypretty well tested... Why not just go with AC_PROG_INSTALL since it gets tested by all the other gnu software installations anyway. If there are special cases that it doesn't grok we can always put it inside a conditional based on a --with-install=/your/favorite/install/program configure option. I doubt we really will need that, though. Cheers, Brook
Seems like this issue gets more than its fair share of attention. I started a round of discussion by pointing out that /usr/ucb/install worked on Solaris while the default one didn't. It's just not a complicated program and many other open-source packages (like gcc I think) find it easier to just bundle a shell script rather than decipher which existing program (if any) do what they want. Go for it Tom (Lane). Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu