Re: 7.2 RPMs

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