Re: 7.2 RPMs

On Sunday 16 September 2001 11:22 pm, Peter Eisentraut wrote:
> I just took a dreadful look at the RPMs.  I've managed to build something
> that resembles a 7.2 package, but there are a number of things that we
> should talk about so this ends up being useful.

First, thanks for taking a look.  However,I don't think 'dreadful' is a 
really appropriate word here.  But I'll let it slide. RPM packaging in 
general can be a dreadful experience -- and that's what I'm going to assume 
that you meant.

And, while your list is a usable list of things, the lack of addressing any 
of these items in no way prevents a package of 7.2 from being 'useful' for 
various degrees of usefulness.

> * The {pgaccess} parameter doesn't do anything AFAICT.  PgAccess is
> installed whenever Tk support is configured (which is correct, IMO).
> Maybe this is just a legacy item?

As I've not yet had the time to build any 7.2 RPMsets, I'll have to look.  It 
may very well be legacy if 7.2's makefiles do such a decision as to install 
pgaccess and where to install it.

But, pgaccess!=tk_client_support and might not even be desired by a tk client 
user.

> * I removed the {plperl} parameter, because PL/Perl now builds by default
> on Linux.  Should plperl continue to stay its own package?  I'd say yes,
> because you don't need in on every client.

PL/perl requires a dynamic load libperl.so -- which Red Hat doesn't ship.  If 
configure can test for a dynamic libperl (which is being done in the makefile 
as of 7.1.3), then that's where that decision ought to be made.  However, 
Karl DeBisschop can shed much light on this particular subject, and his 
opinion should be weighed, as he knowsof some interesting situations.

As to it remaining a separate package -- absolutely.  PL/perl is a 
server-side package, while the perl client might be installed without a 
server on its system.  Don't want to force the server on a perl client 
machine.

> * Related to previous, the tcl package currently includes client and
> server components.  I'd say this is more useful as two separate packages.

> * Similar issues with PL/Python

I agree, and had planned on doing just this.

> * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is
> in -tcl?  What about libpgtcl.h?  Currently, the -devel package has an
> implicit dependency on Tcl, which should probably not be there.

Huh?  The libs package is intended to be the base client libraries that all 
clients need.  The tcl library is only needed by the tcl client.  The 
libpgtcl.a static lib is only needed in development, and doesn't depend upon 
tcl directly.  Although I have yet to see a RedHat system without tcl 
installed....  The tcl package could, I guess, inherit libpgtcl.a from the 
_devel_ package (libpgtcl.a lives there, not in libs) without problems.

> * How long do we want to keep the libpq.so.2.0 symlink?

Good question.  Trond's answer is a 'long time' -- When is the next major 
uprev in the library going to be?  This needs to be researched -- the 
question that needs answering here is 'how many third-party packages (such as 
the php postgresql interface; the DBI postgresql interface, etc) are going to 
be broken by this?'

> * I fail to understand the motivation behind the way the -contrib package
> is done.  You seem to be installing the source code.  I scrapped that and
> installed the binaries the way it was designed to be.

Contrib, to my eyes, is both an example set as well as useful stuff.  As 7.1 
was the first setof RPM's with contrib compiled at all (previously, the 
entire contrib tree was packaged as source code for documentation!), having 
the source as well enables examples -- however, I understand both sides of 
that.

However, I'm concerned about your wording 'the way it was designed to be' -- 
would you mind explaining exactly what you meant (a copy of your spec file 
will explain far better than any narrative could, BTW)?

> * The -docs package is misleading.  Maybe it should be called -docs-devel
> or something.  However, I'm having a hard time understanding how people
> can make use of this.

'docs-sgml' perhaps?  Maybe they want to try their hand at using an SGML 
editor/publishing system to generate various docs formats?  It was previously 
packaged as part of the main package and I split it out.

> * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> that conveys a semantic difference from pg_dump.  Possibly, these files
> should not be installed into /usr/bin if they're not general purpose.

Hmmm.  Any suggestions as to location and name?  Might I suggest 
'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too 
inflammatory? :-)  However, I tend to agree -- /usr/bin might not be the best 
location for these scripts.

> * What about the JDBC driver?  I think the driver should be compiled in
> place by whatever JDK the build system provides.

Got an open source JDK suggestion?  One that is _standard_ for the target 
distributions?

> * Start thinking about how to package National Language Support.

Explain what you mean by this.

> * Lot's of dependencies failing to be declared.

Most dependencies are automatic and do not need declaration.  Can you give a 
list of undeclared dependencies that are not auto generated during the build 
that are not part of a standard development system for building, and part of 
a standard installation for run-time?

> There are also a number of plain bug fixes that need to be integrated.

Ok.  List, please?

A copy of your initial spec file and patchset would also be useful.

Once again, thanks for the look-through.  You previous look-throughs wevery 
useful, and I appreciate them.  And I'll go ahead and apologize if my 
comments seem to be short and maybe even grumpy -- I just got done with an 80 
hour week involving a 25 kilowatt AM broadcast transmitter installation, so 
I'm not at my best at the moment -- but I'm not intending to be short or 
grumpy (although my wife might disagree.... :-)).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11