7.2 RPMs

Peter Eisentraut wrote:

<snip>

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

Don't know about the rest of this stuff, but I totally agree here.
There should be a dependancy on Ant and some kind of JDK, and it should
compile the driver specifically. This way the user I reckon the user is
WAY more likely to have something which works well for them.

Bumped into a problem with this just over a week ago.

Regards and best wishes,

Justin Clift

<snip>

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Peter Eisentraut <peter_e@gmx.net> writes:

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.

* 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
# pgaccess installation
pushd src/bin
install -m 755 pgaccess/pgaccess $RPM_BUILD_ROOT/usr/bin
mkdir -p $RPM_BUILD_ROOT/usr/share/pgsql/pgaccess
install -m 644 pgaccess/main.tcl $RPM_BUILD_ROOT/usr/share/pgsql/pgaccess
tar cf - pgaccess/lib pgaccess/images | tar xf - -C $RPM_BUILD_ROOT/usr/share/pgsql
cp -a pgaccess/doc/html ../../doc/pgaccess
cp pgaccess/demo/*.sql ../../doc/pgaccess
popd
%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.

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

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

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

It might, if you imply that tcl is useful at all ;).

* Similar issues with PL/Python

Same issues wrt. static libraries as for perl, but could easily be
separated.

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

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

A long time :)

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

Often the only source of docs, but I wouldn't miss it. I've often
wanted to kill this inconsistency myself.

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

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

* Start thinking about how to package National Language Support.

Look at the find_lang macro.

* Lot's of dependencies failing to be declared.

For the finished packages, those are generated automatically. As for
build dependencies, I'm unaware of any missing ones.

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

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

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

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.

On Monday 17 September 2001 02:21 pm, Peter Eisentraut wrote:

Trond Eivind Glomsr�d writes:

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

Built!=shipped in the RPMset. Lots of things are built -- but if it's not in
the %files list, it don't get packaged.

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

I've already suggested a name that fits the purpose.

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

To use a compiled bytecode java application built against our JDBC with a JRE?

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

Yes, we would have to build it now. However, the question still looms:
_which_ JDK should be used to build it for maximum JVM/JRE compatibility for
the bytecode distribution? I've asked this question before, and no consensus
was reached.

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?

I will have time shortly.

It has been discussed in the past on two separate occassions about putting
the spec file into CVS at postgresql.org, but, again, no consensus was
reached and no action was taken by core to implement that. If I had to I
could set up my own CVS repository -- but I haven't needed to as yet.

Send a patch to me and Trond against the last PGDG release specfile. If you
change the patchset, it needs to be included, as well as patches to any
scripts distributed.

The preliminary spec file patch is already the same size as the spec file.

??? That's pretty big. E-mail me and Trond your changes, please.

We're getting ready to go into beta, and I was getting ready to ramp up to
deal with 7.2beta RPMs anyway. This just quickens the issue.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Trond Eivind Glomsr�d writes:

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.

Libtool seems to think otherwise. And the people who provided the
patches to libtool are the ones who should know best.

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

You don't break binary compatibility by providing a shared library
alongside a static one.

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

Peter Eisentraut <peter_e@gmx.net> writes:

Trond Eivind Glomsr�d writes:

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.

Libtool seems to think otherwise. And the people who provided the
patches to libtool are the ones who should know best.

Dynamic code works on those platforms. What doesn't work is dlopen()
of code not compiled with -fpic (which means extensions linking with
static libraries). I've not seen libtool claim otherwise, but it would
be broken. Another can of worms is nsswitch inside glibc, which in
some circumstances will use a dynamic module in a statically linked
program.

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

You don't break binary compatibility by providing a shared library
alongside a static one.

This mean backward as well... eg. perl packages for RHL 7.1 should run
on RHL 7 as well. Same for RHL 7.2, if we make such a release.

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

Lamar Owen writes:

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.

...useful in the sense that the work I'm doing becomes useful.

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

My interpretation of dependency is "this file cannot be made use of unless
that package is installed". Hence, libpgtcl.h and libpgtcl.a have a
dependency on the tcl package and therefore the postgresql-devel package
has that same dependency. That is one thing, and other interpretations
may be valid.

The other thing is that no matter how you arrange it, libpgtcl.a and
libpgtcl.so should be in the same package. I placed them in -devel for
now since that is what you seemed to be intending anyway.

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

"Never" is my best guess.

Contrib, to my eyes, is both an example set as well as useful stuff.

That used to be sort of true. Currently, contrib is more "useful stuff"
than example. Examples are in the documentation and the tutorial
directory.

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

I mean contrib is intended to be compiled, installed, and used.

'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML
editor/publishing system to generate various docs formats?

Difficult without having a real source tree available. Plus, people that
want to work on documentation also have the option of getting the
postgresql-docs-xxx.tar.gz source package that contains the documentation
sources.

Hmmm. Any suggestions as to location and name? Might I suggest
'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too
inflammatory? :-)

No, but it's longer than the 14 characters that POSIX allows for file
names. ;-) But "upgrade" is a reasonable start.

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

There is no standard C compiler in the target distributions either...

You don't need a standard JDK either. You want to build the driver to fit
the JDK that the distribution provides. If the distribution doesn't
provide Java support, you don't need a JDBC driver.

Note that the choice of JDK is actually hidden from the build process.
You just need Ant, which comes in RPM form.

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

On Monday 17 September 2001 05:40 pm, Trond Eivind Glomsr�d wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

You don't break binary compatibility by providing a shared library
alongside a static one.

This mean backward as well... eg. perl packages for RHL 7.1 should run
on RHL 7 as well. Same for RHL 7.2, if we make such a release.

Distributors' needs are very different from our needs, Peter. Maybe a
potential Red Hat 8 can do such. However, the backwards compatibilty issue
is some rub.

Our PGDG packages, OTOH, don't have to be limited in that way. Which is one
reason you may want to start there, not the Red H?at package (which is close,
but not identical, to ours).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Monday 17 September 2001 05:44 pm, Peter Eisentraut wrote:

...useful in the sense that the work I'm doing becomes useful.

Ok. My mind is a little muddy right now, and different interpretations of
wordings aren't coming easily.

The other thing is that no matter how you arrange it, libpgtcl.a and
libpgtcl.so should be in the same package. I placed them in -devel for
now since that is what you seemed to be intending anyway.

Yes, that is and was my intentions; I just missed the significance of what
you said. Of course, the .so and the .a need to be together in this instance
(like the libpq.so/libpq.a instance as well, which was addressed earlier in
the 7.1.x RPMset cycle).

Contrib, to my eyes, is both an example set as well as useful stuff.

That used to be sort of true. Currently, contrib is more "useful stuff"
than example. Examples are in the documentation and the tutorial
directory.

Then the change is valid.

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

I mean contrib is intended to be compiled, installed, and used.

Ok. I was more talking about location in the filesystem, but I get your
point.

'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML
editor/publishing system to generate various docs formats?

Difficult without having a real source tree available.

Hmmm. I've not tried to do anything with the SGML yet....

Hmmm. Any suggestions as to location and name? Might I suggest
'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too
inflammatory? :-)

No, but it's longer than the 14 characters that POSIX allows for file
names. ;-) But "upgrade" is a reasonable start.

But we already had a pg_upgrade in the tarball. 'pg_migrate' perhaps? And
it _is_ a kludge.

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

There is no standard C compiler in the target distributions either...

Gcc is the de facto linux distribution standard, and one can reasonably
assume that a standard C compiler is present. The same is not true of JDK's,
AFAIK.

Note that the choice of JDK is actually hidden from the build process.
You just need Ant, which comes in RPM form.

Hmmm. How does one get started with 'Ant' and a JDK? I personally don't use
Java -- but heretofore it's been easy to get jars of the JDBC to package for
people who do use Java. Is a JDBC RPM package something people are actively
using? I _have_ received a few questions from people trying to use the JDBC
RPM, so I think it is a useful thing to have.

Somebody who knows Java: enlighten me on the portability or lack thereof of
our distributed JDBC RPM's jar, please. If I can build a reasonably portable
jar of our JDBC,I'm willing to try.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11