"Steve Wolfe" <steve@iboats.com> writes:
> Now, play some villanous music, and enter RedHat wearing a black cape,
> with small, beedy eyes.
I don't have a cape, but I do have a red hat. And blue eyes, normal size.
> They insist that an OS should not touch /usr/local, and they're
> right about that. However, if you choose to download the Postgres
> RPM and install it via RPM yourself, they seem to interpret that as
> "the OS touching /usr/local", and it won't happen.
For managed distributions, the standard way of doing things is "if
it's in the package format, put it in /usr. /usr/local is for things
not managed by this system (rpm, deb, whatever)" (typically this
means things installed by loki :), things compiled locally without
package systems (configure && make install) etc.
> You will end up with the binaries in /bin or /usr/bin, the libraries in /lib
> or /usr/lib, and the postgres data directory under /var, if I
> recall.
You'll end up with the binaries in /usr/bin, the libraries in /usr/lib
and the data in /var/lib/pgsql. Like it should be :)
> In short, it spreads things out quite a bit, making it a headache to track
> things down.
?
> So, the problem at that point is that if you mix installations from
> source and RPM, you have conflicts with multiple library and binary
> versions, with your path determining which one actually gets called. Very
> ugly. So, either stick with RPM's, and get RedHat's ideas about where
> libraries and binaries should go (and the accompanying mess)
No mess, sanity is included.
> or stick to the source, and get them where the developpers meant
> them to go, but don't mix them.
"mean them to go" - that this is the default location doesn't mean
they are meant to go there. The default values of autoconf point at
where it would go if it was locally compiled and installed. A
distribution is another scenario - you wouldn't claim that e.g. bash
should be in /usr/local/bin because that's the default autoconf
location, would you?
--
Trond Eivind Glomsrød
Red Hat, Inc.
