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