Re: 7.2 RPMs

Trond Eivind Glomsrød writes:

> > * 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?
>
> For 7.1.3, it does make a difference....
>
> %if %pgaccess
[...]
> %endif
>
> (in addition to the actual package). The 7.2 build procedure might
> differ. It's still useful to have several packages, as it under some
> circumstances it would be useful to have tk bindings but not ship
> pgaccess. E.g. if you were to ship an Asian version, this segregation
> might be useful.

Given that pgtksh is rather small in size I don't know if that's worth the
contortions.  However, note that pgaccess is still built if you turn on Tk
but turn off %pgaccess.  (There was also a plan to make pgaccess use
pgtksh, but it's not happening for 7.2.)

> Not only that, but you very often don't want to build it. If you have
> a static perl package, plperl can't be created. It will sort of work
> on IA32, but bomb out elsewhere. Ideally, the configure process should
> figure out this on it's own (you can't create dynamic extensions
> linking in a static lib).

There are provisions in the source for figuring this out automatically.
Currently, the only "figuring" it does is to allow it on Linux.  (It is my
understanding that it works on Linux independent of the CPU architecture.
In the past there have been problems with insufficient dynamic loader
implementations, but there is no principal design obstacle.)

But it would really be of advantage if distributors (i.e., you) supplied a
shared libperl by default.  There are at least two high profile users
(PostgreSQL and Apache) running into this problem.

> > * 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.
>
> They are programs serving specific dumping purposes.

Maybe they should be named to reflect these purposes?  Currently,
postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
conveys the meaning of "Red Hat's (better/different) pg_dump".

> > * What about the JDBC driver?  I think the driver should be compiled in
> > place by whatever JDK the build system provides.
>
> Many build systems don't have a JDK, as there are no open (or even
> distributable) JDKs.

From Red Hat I would have expected the answer "use gcj". ;-)  (I don't
know how complete the class library is there, and Ant probably doesn't
support it anyway.)  However, two questions arise:

* If the build system doesn't have a JDK, why do you need a JDBC driver?

* There is currently no "official" source of PostgreSQL JDBC driver
binaries.  So I don't know how you plan to obtain a precompiled jar
without making it yourself.


Well, do you have time to work on this and do you keep the RPM input files
under version control somewhere, so I can send some incremental patches?
The preliminary spec file patch is already the same size as the spec file.
:-/

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter