Re: 7.2 RPMs

Peter Eisentraut <peter_e@gmx.net> writes:

> 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.)

It may be built, but at least you don't get the package... Personally,
I wouldn't mind separating the database core from all the other things
bundled with it (drivers, support programs). It seems a little cleaner.

> > 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.)

No. It works on IA32, but breaks elsewhere.
> 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.

It's not unlikely to happen for the next major series (we try hard to
stay binary compatible within a series).
> 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".

It was basically "doh, the existing dump script is very broken and we
freeze very soon" a release or two ago. I think Lamar was the one who
discoverd it and I the one who wrote it rather quickly.
> > > * 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:

gcj is nice, but far from complete. It's also Java 1.1 without AWT,
AFAIR, and most interesting stuff use 1.2 and up now.

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

That you can use with gcj :). The main reason it's useful is that
other can install their own JDK, typically when running servlets or
other server based Java apps.

> 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?

If you send it, I can have a first look. As for time, that's something
other people have. And when I have it, I don't have anything to use it
for either (maxed out with 5 weeks unused vacation now, but have no
idea what to use most of it for)

-- 
Trond Eivind Glomsrød
Red Hat, Inc.