I hope I'm not overstepping here, and not sure if I'm allowed to reply,
but here goes:
It looks like there are two approaches to this:
1) Unify the init scripts so they work all the time everywhere.
2) Generate the scripts as needed per distribution and risk being out of
Option 1 seems like more work for overworked Open Source developers so I
wouldn't choose that.
Option 2 seems more logical since they are in the contrib directory, it
is assumed they could be out of date. I approach contrib as a "This is a
good starting point but I may have to modify what is here." If it can
be kept up to date, that's fine, but shouldn't be a priority. Besides,
if someone (business) really needs this, then they can pay your support
staff for on the spot fixes and installation knowledge.
Tom Lane wrote:
>Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>Tom Lane wrote:
>>>We could push the RPM initscript into the contrib item, but I fear
>>>we'd forget again to keep it up to date.
>>I doubt that the RPM init script is going to be portable to all Linux
>>systems. I think it's useful to have a generic script there for people
>>doing source installations.
>Well, the other side of that coin is that an unmaintained script isn't
>going to be portable to all Linux systems either, as per the OP's point
>that what's there now simply does not work on a SELinux-enabled machine.
>At least the RPM script gets tested regularly.
>I will grant you that the contrib script ought to default to assuming
>installation paths under /usr/local instead of where the RPMs put
>things, but beyond that I'm not sure what's unportable in the current
>RPM init scripts.
> regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Mario||Date: 2006-03-20 17:24:41|
|Subject: Problem in connection|
|Previous:||From: Mattias Kregert||Date: 2006-03-20 15:07:39|
|Subject: BUG #2342: Extremely bad performance on a specific query, compared to 7.4|