Thread: Re: [GENERAL] Compiling to RPM setup/filesystem layout

Re: [GENERAL] Compiling to RPM setup/filesystem layout

From
Lamar Owen
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 31 May 2001 16:22, Steve Wolfe wrote:
> something else fills up /var, PG isn't hosed.  And if PG fills up it's
> partition, other services aren't hosed.

Make a partition mounted on /var/lib/pgsql. :-)

>     Now, play some villanous music, and enter RedHat wearing a black cape,
> with small, beedy eyes.  They insist that an OS should not touch
> /usr/local, and they're right about that.  However, if you choose to

Linux Standards Base and the Filesystem Hierarchy Standard sets that policy,
not Red Hat. And I happen to think it installs to the right place, IMHO. :-)
And Red Hat ain't no villain -- unless you're a BSD partisan who thinks Red
Hat is responsible for popularizing Linux beyond its worth (that,
incidentally, is a friendly dig at scrappy.....)  If you like Linux, you
should absolutely adore Red Hat -- if nothing else, for payrolling Alan Cox
and the stable kernels.

> 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.  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.  In
> short, it spreads things out quite a bit, making it a headache to track
> things down.

Running rpm -ql on the RPMset is too much of a hassle, right? Removing all
traces of the RPMset is easier than removing all traces of a from-source
install.

> ugly.  So, either stick with RPM's, and get RedHat's ideas about where
> libraries and binaries should go (and the accompanying mess), or stick to
> the source, and get them where the developpers meant them to go, but don't
> mix them.

Developing a great RDBMS != knowing where to put that RDBMS in the systems
context. Sorry.

Although, as I _am_ mentioned as a 'Developer' on the globe, and the RPM puts
the files where I mean for them to go... well, you decide the worth of that.

And followup to the PORTS list, as this is a ports, not a general, issue.
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7FrHx5kGGI8vV9eERAqQuAKDqga82vmuJukgprQbvV84wnO+OJgCcCWrr
hcuKxQvjny3e4V5m0Ky1hy0=
=EhNS
-----END PGP SIGNATURE-----

Re: [GENERAL] Compiling to RPM setup/filesystem layout

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Running rpm -ql on the RPMset is too much of a hassle, right? Removing all
> traces of the RPMset is easier than removing all traces of a from-source
> install.

make uninstall

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


Re: Re: [GENERAL] Compiling to RPM setup/filesystem layout

From
Lamar Owen
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 01 June 2001 11:07, Peter Eisentraut wrote:
> Lamar Owen writes:
> > Running rpm -ql on the RPMset is too much of a hassle, right? Removing
> > all traces of the RPMset is easier than removing all traces of a
> > from-source install.

> make uninstall

But that doesn't remove _all_ traces, does it? :-)

My point is that removing and upgrading the RPMset isn't a big pain.
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7F/y55kGGI8vV9eERAhdgAJ4mFwTtcnZr9rP4BkQKwUGdwJ7r6gCfXVA0
oBbQMfwl/69YN7FVu7t7zZo=
=Wcme
-----END PGP SIGNATURE-----

Re: Re: [GENERAL] Compiling to RPM setup/filesystem layout

From
Peter Eisentraut
Date:
Lamar Owen writes:

> > make uninstall
>
> But that doesn't remove _all_ traces, does it? :-)

It would in theory, if it weren't for some nonsense like MakeMaker.

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter