Re: 7.2 RPMs

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2 RPMs
Date: 2001-09-17 19:02:36
Message-ID: xuylmjdwshf.fsf@halden.devel.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-09-17 19:07:36 Re: [GENERAL] pg_dump error - LOCALIZATION PROBLEM
Previous Message Lamar Owen 2001-09-17 18:23:05 Re: 7.2 RPMs