From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Marti Raudsepp <marti(at)juffo(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL 9.3 beta breaks some extensions "make install" |
Date: | 2013-05-15 14:05:05 |
Message-ID: | 25425.1368626705@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> That said, I'm obviously outnumbered here. What about the following
> compromise: Use the configure-selected install program inside
> PostgreSQL (which we can test easily), and use install-sh under
> USE_PGXS? Admittedly, the make install time of extensions is probably
> not an issue.
That works for me, since as you say we can easily fix any such bugs
in the core code. The scary thing about this for extension authors
is that they may very well see no bug in their own testing, only to
have their packages fall over in the wild. We shouldn't make each
author who's copied that code rediscover the problem for themselves
that expensively.
> (The affected extensions will still be buggy because users can still
> substitute their own install programs. We're just hiding the issue for
> a while.)
I'm not following this argument. The old makefile coding explicitly set
INSTALL = $(SHELL) $(top_srcdir)/config/install-sh -c
The only way I can see that that would be overridden is an explicit
make INSTALL=/my/random/script install
and surely we cannot guarantee that things don't break when you do
something like that. There are hundreds of ways you can break
the build if you mess with makefile variables. So I'm not prepared
to call it a bug if that doesn't work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2013-05-15 14:15:40 | Re: PostgreSQL 9.3 beta breaks some extensions "make install" |
Previous Message | Kyotaro HORIGUCHI | 2013-05-15 14:04:27 | Re: Logging of PAM Authentication Failure |