RPM changes for 7.1.

Lamar Owen writes:

1.) Addition of a postgresql-lib subpackage.

What exactly will be in this one?

One major gripe about the RPMs I have is that the client package is named
"postgresql". If I install "postgresql" I'd sort of expect a database
server. I suggest naming the package "postgresql-clients".

It is hard for a malicious cracker to compile cracking tools or
rootkits on my machine when no compiler exists on my machine.

Why would a cracker need to compile the rootkit on your machine? He can
just build it on his and upload it. If your intent is on making things
inconvenient for crackers then you're missing the point. But I
disgress...

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

On Mon, Dec 11, 2000 at 02:09:35PM -0500, Lamar Owen wrote:

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

Ah, _that's_ why my procmail filter missed this one! Couldn't think of
why you'd email me about RPMs directly, since I use Oliver's debs.

Looks good, though, and the analysis applies regardless of the details of
which packing system is used. You and Oliver would be well advised to
consider using the same scheme, as much as possible.

Here's the current set of Debian packages derived from the main postgresql
source, with their descriptions:

pgaccess - Tk/Tcl front-end for PostgreSQL database
postgresql-slink - Package to ease upgrade of postgresql from Debian 2.1 to 2.2
libpgsql2 - Shared library libpq.so.2 for PostgreSQL
postgresql-contrib - Additional facilities for PostgreSQL
postgresql-test - Regression test suite for PostgreSQL
libpgjava - Java database (JDBC) driver for PostgreSQL
postgresql-pl - A procedural language for PostgreSQL
ecpg - Embedded SQL for PostgreSQL
libpgtcl - Tcl/Tk library and front-end for PostgreSQL.
libpgsql - Library for connecting to PostgreSQL 6.3 backend
postgresql-dev - Header files for libpq (postgresql library)
postgresql - Object-relational SQL database, descended from POSTGRES.
postgresql-doc - Documentation for the PostgreSQL database.
postgresql-client - Front-end programs for PostgreSQL
libpgperl - Perl modules for PostgreSQL.
odbc-postgresql - ODBC support for PostgreSQL
task-database-pg - PostgreSQL database

the -pl package contains both plpgsql and pltcl. The descripton there
needs updating. The task- package is an empty package, with dependencies
that pull in a 'recommended set' of packages to fullfill a given task, in
this case, running a postgresql database installation. It pulls in:

postgresql
postgresql-client
pgaccess
ecpg
postgresql-doc
postgresql-pl
postgresql-contrib
php-pgsql

As you can see, Oliver has also taken the route of allowing the admin
to load the minimum set of software for any configuration, except for
the procedural languages on the server itself. Debian has package naming
policies for library and development packages. Libraries are named libfoo,
while development packages (usually header files) are foo-dev.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

Peter Eisentraut wrote:

Lamar Owen writes:

1.) Addition of a postgresql-lib subpackage.

What exactly will be in this one?

libpq and associated symlinks.

One major gripe about the RPMs I have is that the client package is named
"postgresql". If I install "postgresql" I'd sort of expect a database
server. I suggest naming the package "postgresql-clients".

I'm actually considering removing the 'postgresql' package altogether --
and replace it with postgresql-libs, postgresql-docs, and
postgresql-psql. Not pretty, though. But I do get your point -- and
agree with it to an extent.

The postgresql-client package existed once -- and the current RPM's
Obsoletes: it. That can be changed if need be.

It is hard for a malicious cracker to compile cracking tools or
rootkits on my machine when no compiler exists on my machine.

Why would a cracker need to compile the rootkit on your machine? He can
just build it on his and upload it. If your intent is on making things
inconvenient for crackers then you're missing the point.

The time I was cracked into the cracker compiled the rootkit on my box
-- libc versioning difficulties and all of older RedHat's. This was
when there were major changes between RedHat 4.x (which I was running at
the time) and RedHat 5.0, which was more popular by that time. The more
stumblingblocks I put in the cracker's way, the better I like it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

1.) Addition of a postgresql-lib subpackage.

What exactly will be in this one?
One major gripe about the RPMs I have is that the client package is named
"postgresql". If I install "postgresql" I'd sort of expect a database
server. I suggest naming the package "postgresql-clients".

We had it this way for some time, and I found it annoying for at least a
couple of reasons stemming from the observation that in a real
distributed system, there will be more clients than servers:

1) The docs etc should colocate with clients, and RPMs make that more
difficult if the "primary package" does not have the base name of the
total package. If the docs (or at least some docs) are traveling with
the clients, and if it would be easiest to find them in
/usr/doc/postgresql-7.1/, then that package should have the docs (it
does). If Lamar moves them to a -docs package, then they will show up in
/usr/doc/postgresql-docs-7.1/ which is redundantly named and somewhat
obscure to guessing.

2) The base package should be able to be installed in a useful way by
itself. For a single-machine installation, both will be installed
anyway, but in general a server cannot be accessed or configured without
the client interfaces available.

- Thomas

"Ross J. Reedstrom" wrote:

Here's the current set of Debian packages derived from the main postgresql
source, with their descriptions:

...

the -pl package contains both plpgsql and pltcl. The descripton there
needs updating.

This is a mistake, and the dependencies aren't right. pltcl ought
to be in with libpgtcl, to share the dependency on tcl. I suppose
I originally classed the PLs together, but there's plperl as well now.
I'll be fixing this soon.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Be of good courage, and he shall strengthen your
heart, all ye that hope in the LORD."
Psalms 31:24

Thomas Lockhart wrote:

1.) Addition of a postgresql-lib subpackage.

What exactly will be in this one?
One major gripe about the RPMs I have is that the client package is named
"postgresql". If I install "postgresql" I'd sort of expect a database
server. I suggest naming the package "postgresql-clients".

We had it this way for some time, and I found it annoying for at least a
couple of reasons stemming from the observation that in a real
distributed system, there will be more clients than servers:

1) The docs etc should colocate with clients, and RPMs make that more

[snip]

does). If Lamar moves them to a -docs package, then they will show up in
/usr/doc/postgresql-docs-7.1/ which is redundantly named and somewhat
obscure to guessing.

We already have the problem with postgresql-tk -- the pgaccess docs get
placed in the postgresql-tk-x.y.z directory under the docs. There are
some things I can do with that -- I'll have to investigate. The %doc
directive can be made do some other things.

However, I am not leaning towards a separate docs subpackage -- it was
suggested to me, and I placed it on my list for discussion. However, I
_am_ inclined to put the PostScript docs in separate packaging, once I
get the %doc directive to do what I want it to do. But the man pages and
HTML docs (plus and index page I need to put together) should, IMO, stay
in the 'main' package. But what else belongs there?

SuSE is already shipping a separate libs RPM (although their naming has
thus far been somewhat different due to legacy considerations --
hopefully that will change to allow naming consistency amongst other
cross-distribution consistencies). The suggestion for a separate -libs
subpackage (which would be very small, BTW) was made by the SuSE
maintainer, Reinhard Max. And I tend to agree with his reasoning.

2) The base package should be able to be installed in a useful way by
itself. For a single-machine installation, both will be installed
anyway, but in general a server cannot be accessed or configured without
the client interfaces available.

This is most definitely a valid point. But, I still go back to the FAQ
of 'I installed the postgresql RPM, and I can't find initdb to start a
database!'

Making the postgresql package depend upon the postgresql-libs package is
easy enough. That means you do have at leats two packages to install.
And, that dependency won't interfere with OS installs, as they can
automatically resolve dependencies such as that.

No, better instructions on the download page, detailing which package to
install for functionality required, should be applied. I can write that
doc easy enough.

As to 'superpackages' that simply require other packages in order to
install, well, that may be a possibility. In the RPM context, that will
mean an empty RPM with an ugly marriage of a dependency list, and a
%post scriptlet that does an 'rpm -e' of itself. I cringe thinking
about recursively calling RPM inside a scriptlet :-).... Although, I
_have_ seen it done.

I am a firm beliver in the client-server split -- but I am open to
suggestion as to the best way of documenting said split.

One example of a split that seems to work well (AFAIK) is the amanda
network backup tool.
There are four packages:
amanda
amanda-client
amanda-server
amanda-devel.

The main package contains files common to the client and server. Amanda
(the Advanced Maryland Automatic Network Disk Archiver) is similar
enough to the postgresql situation to be a good analogy -- the client
can exist on a machine with no server, and vice-versa.

The client subpackage contains files only needed by the client, and the
server package contains files only needed by the server. The devel
subpackage contains the static libs and headers for building custom apps
that might need to connect to an amanda server.

However, we have a different split: the main package is also the
client. But, just what files are really _common_ to a server
installation versus a client installation? Well, the psql cli is
_required_ for a server installation, really -- unless you want to not
run pgdump and the standard restore on the server machine. The problem
is that the upgrade to a new major version requires a dump/restore --
meaning the server package really _needs_ the cli, as well as the libpq
client-side libs.

So, it _is_ appropriate for us to have the main package of common files
have the client stuff as well.

Although there is precedent for a 'postgresql-common' RPM -- see the
netscape packages -- you have netscape-common, netscape-navigator, and
netscape-communicator packages -- but there are some differences there
as well.

Having the libs split out means someone can install postgresql-libs and
postgresql-perl and have a meaningful perl client, for very little
space. Of course, you can install the main postgresql RPM with the
--nodocs directive and not have any of the docs install for a lean main
package installation.

Or postgresql-libs and php (and php-pgsql) for a PHP/Apache
installation. No need to pull in _any_ cli or much of the docs.
Although if they want the docs, then they can install the main package
(which is predominately docs). The rest of the main package is
currently the c and c++ libs and the base client software (the create*
and drop* scripts, pg_dump, pg_dumpall, vacuumdb, and psql).

Comments?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

We already have the problem with postgresql-tk -- the pgaccess docs get
placed in the postgresql-tk-x.y.z directory under the docs.

I find it somewhat odd that pgaccess is thrown together with pgtksh.
Mostly they have nothing to do with each other besides both being somehow
connected with Tcl/Tk. That's like a postgresql-c package: nonsense.

Similarly, I find it not useful that PL/Perl and thrown together with
Pg.pm, and PL/Tcl is thrown together with pgtclsh. Maybe you want to make
a separate postgresql-server-{perl,tcl} package. I think you already
suggested that.

However, I am not leaning towards a separate docs subpackage -- it was
suggested to me, and I placed it on my list for discussion.

I don't think this is a bad idea. Maybe people only want to install the
docs once in their network and make them available via a web server. I
did it that way.

Making the postgresql package depend upon the postgresql-libs package is
easy enough. That means you do have at leats two packages to install.

(On a quiet night you can hear the Debian users laughing...)

One example of a split that seems to work well (AFAIK) is the amanda
network backup tool.

The main package contains files common to the client and server.

In PostgreSQL there are, strictly speaking, no files in common to client
and server.

Two more points:

* createlang, droplang, and pg_id should be in the server package.

* Maybe you want to create a postgresql-server-devel package with the
backend header files. These are needed rather seldom.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Similarly, I find it not useful that PL/Perl and thrown together with
Pg.pm, and PL/Tcl is thrown together with pgtclsh. Maybe you want to make
a separate postgresql-server-{perl,tcl} package. I think you already
suggested that.

I agree -- I use DBD, and thus do not feel the need for Pg.pm, but I do use
PL/Perl.

However, I am not leaning towards a separate docs subpackage -- it was
suggested to me, and I placed it on my list for discussion.

I don't think this is a bad idea. Maybe people only want to install the
docs once in their network and make them available via a web server. I
did it that way.

I have created docs packages in the past. Until I was reminded of the
--excludedocs option for rpm. Actually, I may have been one who suggested a
docs package for PostgreSQL)

Making the postgresql package depend upon the postgresql-libs package is
easy enough. That means you do have at leats two packages to install.

(On a quiet night you can hear the Debian users laughing...)

One example of a split that seems to work well (AFAIK) is the amanda
network backup tool.

The main package contains files common to the client and server.

In PostgreSQL there are, strictly speaking, no files in common to client
and server.

Two more points:

* createlang, droplang, and pg_id should be in the server package.

* Maybe you want to create a postgresql-server-devel package with the
backend header files. These are needed rather seldom.

Would we have postgresql-server-devel and postgresql-clients-devel?
This splits things up rather finely, but it seems consistent, and I
tend to like that -- overall the way Lamar is going sounds very good
to me. And supports a point from an old discussion -- no matter how
good the developers are (and they are great) -- it really helps to
have a good packager as well.

--
Karl DeBisschop kdebisschop@alert.infoplease.com
Learning Network/Information Please http://www.infoplease.com
Netsaint Plugin Developer kdebisschop@users.sourceforge.net

Btw., there's a bug in the RPMs distributed with Red Hat 7.0.

If the postmaster that is under RPM and SysV init control is not running,
then a call '/etc/init.d/postgresql stop' will kill all other postmasters
on the system, for example those that I have running for development.

You should rely on the postmaster.pid file in the data area to find the
process to kill.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Btw., there's a bug in the RPMs distributed with Red Hat 7.0.
If the postmaster that is under RPM and SysV init control is not running,
then a call '/etc/init.d/postgresql stop' will kill all other postmasters
on the system, for example those that I have running for development.

You should rely on the postmaster.pid file in the data area to find the
process to kill.

Duly noted, and my apologies. I'll see what I can do.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

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.

Sounds like a good idea.

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.

The package is 64 k. Why split it?

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.

I've yet to see a security hole from documentation :)

--
Trond Eivind Glomsr�d
Red Hat, Inc.