Thread: RPM changes for 7.1.
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
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/
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
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.