Thread: Patch to install config/missing
Currently, config/missing isn't being installed. This can lead to confusing error messages, such as if Perl isn't found and something needs it [1]. Attached patch adds it to install and uninstall recipes. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
Attachment
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > Currently, config/missing isn't being installed. This can lead to confusing > error messages, such as if Perl isn't found and something needs it [1]. > Attached patch adds it to install and uninstall recipes. I find it somewhat hard to believe this is the right thing to do. But if this isn't right, then I don't know what is right, either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > > Currently, config/missing isn't being installed. This can lead to confusing > > error messages, such as if Perl isn't found and something needs it [1]. > > Attached patch adds it to install and uninstall recipes. > > I find it somewhat hard to believe this is the right thing to do. But > if this isn't right, then I don't know what is right, either. I think 'missing' is as part of the development package as install-sh is -- and we're installing that one, so why not 'missing'? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Currently, config/missing isn't being installed. This can lead to confusing
>> error messages, such as if Perl isn't found and something needs it [1].
>> Attached patch adds it to install and uninstall recipes.
> I find it somewhat hard to believe this is the right thing to do. But
> if this isn't right, then I don't know what is right, either.
Installing our "missing" script seems like a seriously bad idea. For one
thing, as the comments in it note, it's similar but not identical to such
a script that exists in many GNU packages; we could easily create problems
for other packages that rely on other variants of it.
I wonder how much we need that script at all though. If, say, configure
doesn't find bison, what's so wrong with just defining BISON=bison and
letting the usual shell "bison: command not found" error leak through?
I'm not seeing that we get a very large increment of user-friendliness
from interposing the "missing" script. In at least one way it's a net
negative: if you go and install bison after getting the error, you will
have to re-run configure to recover, whereas playing dumb would frequently
have left us with the right configuration output already.
regards, tom lane
On Nov 2, 2015, at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? +1 This would certainly make it easier for downstream use cases, as well. Was not relishing having to parse the PERL variableto find out if Perl was missing. David
On 11/2/15 4:07 PM, Tom Lane wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? I agree. Something like the attached patch.
Attachment
Peter Eisentraut <peter_e@gmx.net> writes:
> On 11/2/15 4:07 PM, Tom Lane wrote:
>> I wonder how much we need that script at all though. If, say, configure
>> doesn't find bison, what's so wrong with just defining BISON=bison and
>> letting the usual shell "bison: command not found" error leak through?
> I agree. Something like the attached patch.
I was thinking more of removing the "missing" script and associated logic
entirely, rather than making PGXS a special case. I think we should do
our best to minimize differences between behaviors in core builds and
PGXS builds, if only because we don't test the latter very much and
might not notice problems there.
regards, tom lane
On 11/11/15 12:34 PM, Tom Lane wrote: > I was thinking more of removing the "missing" script and associated logic > entirely, rather than making PGXS a special case. I think we should do > our best to minimize differences between behaviors in core builds and > PGXS builds, if only because we don't test the latter very much and > might not notice problems there. Well, about a year ago people were arguing for the opposite change in the documentation build. It used to default all the build tool variables to programs that weren't there, and people got all confused about that, so we stuck "missing" in there across the board.
Peter Eisentraut wrote: > On 11/11/15 12:34 PM, Tom Lane wrote: > > I was thinking more of removing the "missing" script and associated logic > > entirely, rather than making PGXS a special case. I think we should do > > our best to minimize differences between behaviors in core builds and > > PGXS builds, if only because we don't test the latter very much and > > might not notice problems there. > > Well, about a year ago people were arguing for the opposite change in > the documentation build. It used to default all the build tool > variables to programs that weren't there, and people got all confused > about that, so we stuck "missing" in there across the board. Ah, right :-( It's obviously difficult to arrange a compromise that pleases everyone here. I think it's fair to keep "missing" for the doc build and remove it from Perl/bison/flex, regardless of pgxs; extensions cannot build doc files anyway. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/11/2015 12:34 PM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On 11/2/15 4:07 PM, Tom Lane wrote:
>>> I wonder how much we need that script at all though. If, say, configure
>>> doesn't find bison, what's so wrong with just defining BISON=bison and
>>> letting the usual shell "bison: command not found" error leak through?
>> I agree. Something like the attached patch.
> I was thinking more of removing the "missing" script and associated logic
> entirely, rather than making PGXS a special case. I think we should do
> our best to minimize differences between behaviors in core builds and
> PGXS builds, if only because we don't test the latter very much and
> might not notice problems there.
>
>
At least two buildfarm members (crake and sitella) build FDWs using
PGXS. Of course, they aren't likely to uncover problems with missing
perl/bison/flex - especially perl ;-) But I don't want people to get the
idea we don't test PGXS regularly, because we do.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/11/2015 12:34 PM, Tom Lane wrote:
>> I was thinking more of removing the "missing" script and associated logic
>> entirely, rather than making PGXS a special case. I think we should do
>> our best to minimize differences between behaviors in core builds and
>> PGXS builds, if only because we don't test the latter very much and
>> might not notice problems there.
> At least two buildfarm members (crake and sitella) build FDWs using
> PGXS. Of course, they aren't likely to uncover problems with missing
> perl/bison/flex - especially perl ;-) But I don't want people to get the
> idea we don't test PGXS regularly, because we do.
I know we have buildfarm coverage, but by its nature that's not going to
exercise scenarios like missing tools. You only find out about problems
of that ilk from manual testing in non-controlled environments. And
I think we have much more of that going on for the core build than for
any add-on.
regards, tom lane
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Peter Eisentraut wrote: >> On 11/11/15 12:34 PM, Tom Lane wrote: >>> I was thinking more of removing the "missing" script and associated logic >>> entirely, rather than making PGXS a special case. >> Well, about a year ago people were arguing for the opposite change in >> the documentation build. It used to default all the build tool >> variables to programs that weren't there, and people got all confused >> about that, so we stuck "missing" in there across the board. > Ah, right :-( It's obviously difficult to arrange a compromise that > pleases everyone here. I think it's fair to keep "missing" for the doc > build and remove it from Perl/bison/flex, regardless of pgxs; extensions > cannot build doc files anyway. I took a closer look at the originally proposed patch at http://www.postgresql.org/message-id/5633BA23.3030201@BlueTreble.com and realized that my worry about it was based on a misconception: I thought it'd get installed into someplace where it might interfere with other packages. But actually, it would get installed into the same place we put install-sh, namely$PREFIX/lib/postgresql/pgxs/config/ (omitting postgresql/ if PREFIX already contains something PG-specific). So the argument that it could break anybody else seems pretty thin. Given our inability to come to a consensus on rejiggering the uses of "missing", I think maybe we should just apply the original patch and call it good. regards, tom lane
Tom Lane wrote: > Given our inability to come to a consensus on rejiggering the uses of > "missing", I think maybe we should just apply the original patch and > call it good. For the record: Tom applied this patch as commit dccf8e9e608824ce15. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services