Thread: RPM changes for 7.1.

RPM changes for 7.1.

From
Lamar Owen
Date:
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

Re: RPM changes for 7.1.

From
Peter Eisentraut
Date:
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/


Re: RPM changes for 7.1.

From
Lamar Owen
Date:
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

Re: RPM changes for 7.1.

From
Thomas Lockhart
Date:
> > 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

Re: RPM changes for 7.1.

From
Lamar Owen
Date:
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

Re: RPM changes for 7.1.

From
Peter Eisentraut
Date:
> 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/


Re: RPM changes for 7.1.

From
Karl DeBisschop
Date:
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

Re: RPM changes for 7.1.

From
Peter Eisentraut
Date:
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/


Re: RPM changes for 7.1.

From
Lamar Owen
Date:
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

Re: [HACKERS] RPM changes for 7.1.

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
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.