RPM changes for 7.1. - Mailing list pgsql-hackers

Ok, after taking in feedback from several RPM users over the last six
months or so, I have come up with a list of possible changes to the
RPMset for PostgreSQL 7.1.  I'd like comments on these changes.  If
there are now comments, I'll go ahead and make the changes.

1.)    Addition of a postgresql-lib subpackage.  Rationale: those using
just the Perl, Python, or Tcl clients may not want the full psql cli and
documetation installed just to use their client.  This package would
simply be the shared object dynamic load libraries necessary for any
client.

2.)    Addition of a postgresql-pltcl subpackage.  Rationale: pl/tcl is
currently included as part of the postgresql-tcl package.  If someone
has the need for a tcl-client ONLY installation, they currently cannot
do so due to the postgresql-tcl package's dependency upon the server
subpackage being loaded.  Likewise, answering the question 'why not put
pl/tcl in the main server package', someone needing the server package,
but not pl/tcl, bight not want to have the full Tcl client installed
just to run a server.

3.)    Cross-distribution mechanisms.  This is a work-in-progress -- but
the eventual goal is a source RPM that will build working packages on
the most popular RPM-based Linux distributions, as well as on other OS's
that have RPM installed (RPM is not just for Linux).

4.)    Addition of a postgresql-docs subpackage.  The main package is
rather large -- there may be those that want the docs but not the other
programs that are in the main package.  Now, the argument can be made
that, if the docs are split out, then there is much less need for a
separate libs subpackage -- and I am inclined to agree.  I am certainly
open to suggestions -- but the gist is that I am looking at ways for the
RPM installation to have the minimum necessary footprint for what the
user wants to do.

I am a minimalist not because of a desire to save disk space -- disk is
cheap, after all.  I am a minimalist because of security -- if I don't
_need_ Perl installed, then I shouldn't be forced to install Perl, for
instance.  A _full_ PostgreSQL RPM installation requires Python, Perl,
Tcl/Tk, and X installed -- and many folk will not need nor will they
want to have X installed on their production database server.  The
security angle is also why I use my own RPM's -- on a machine that has
no compiler.  It is hard for a malicious cracker to compile cracking
tools or rootkits on my machine when no compiler exists on my machine.
I have been cracked into once -- and I don't plan on being so obliging
to the cracker next time one does get in.

The from-source configure allows much flexibility in what parts get
built -- I just want to provide the same or similar flexibility in the
prebuilt RPM installation.

I am cross-posting (via blind copy) this to -hackers since the community
in -hackers is well-versed in system issues such as these.

Replies should go to the -ports list, or directly to me.

Many thanks for the feedback I have received thus far!
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11