Re: 7.2 RPMs - Mailing list pgsql-hackers
From | Lamar Owen |
---|---|
Subject | Re: 7.2 RPMs |
Date | |
Msg-id | 200109171823.OAA27151@www.wgcr.org Whole thread Raw |
In response to | 7.2 RPMs (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: 7.2 RPMs
|
List | pgsql-hackers |
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
pgsql-hackers by date: