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 date.
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.
IMHO
Tom Hollins
-T-
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.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
