Re: RPM changes for 7.1.

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