Обсуждение: 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