autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Depending on system install scripts (was Re: [BUGS] COBOL) (fwd)


From: Peter Eisentraut
Subject: Depending on system install scripts (was Re: [BUGS] COBOL) (fwd)
Date: Thu, 8 Mar 2001 22:23:24 +0100 (CET)

Hi, this came up in our project.  Why, if a package is required to ship
install-sh anyway, do we look for a system install program when this might
just cause weird problems?  (And you know that many system's 'install'
programs are just full of weird problems.)  Compare this to the case of
mkinstalldirs:  we don't check for mkdir -p either before reverting to the
script solution.  Is the install-sh case just a performance issue?

-- 
Peter Eisentraut      address@hidden       http://yi.org/peter-e/

---------- Forwarded message ----------
Date: Thu, 08 Mar 2001 09:59:34 -0500
From: Tom Lane <address@hidden>
To: Jarom Hagen <address@hidden>
Cc: address@hidden, address@hidden
Subject: Depending on system install scripts (was Re: [BUGS] COBOL)

Jarom Hagen <address@hidden> writes:
> Yes, we have an evil COBOL compiler from MicroFocus that put that install
> script there.  I was really confused why postgres wanted a COBOL system. :-)

I've suggested a couple of times that since we include install-sh in our
distro anyway, it's pointless and unnecessarily risky to go looking for
a platform-supplied install program.  However, I could never quite get
anyone else to see the reasoning.  Now that I have this sterling example
to point to, I'm going to start rattling the cage again.  Why don't we
get rid of the configure-time search for 'install', and just always use
our own script?

                        regards, tom lane


> On Wed, Mar 07, 2001 at 07:38:30PM -0500, Tom Lane wrote:
>> Jarom Hagen <address@hidden> writes:
>>> /usr/local/bin/install -c -m 555 postgres /usr/local/pgsql/bin/postgres
>>> You must have a COBOL system present to install this product
>>
>> Weird.  It looks like you have some exceedingly nonstandard program
>> in /usr/local/bin/install --- certainly not what configure thought that
>> that program would do, anyway.  Do you know where that program came from
>> (perhaps a Sun COBOL package)?
>>
>> A nondestructive workaround would be to hand-edit src/Makefile.global's
>> INSTALL variable to refer to our install-sh script (also in src/) rather
>> than /usr/local/bin/install.  However, that install is going to bite a
>> lot of other open-source packages that expect to find a standard-ish
>> install script available, so I'd suggest deleting or at least renaming
>> it...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]