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?

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

* 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

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

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

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

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

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

* Start thinking about how to package National Language Support.

* Lot's of dependencies failing to be declared.

There are also a number of plain bug fixes that need to be integrated.

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


Mon, 17 Sep 2001 05:22:00 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
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

Mon, 17 Sep 2001 13:30:42 +1000
Justin Clift <justin@postgresql.org>
Re: 7.2 RPMs
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.

17 Sep 2001 11:00:21 -0400
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: 7.2 RPMs
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


Mon, 17 Sep 2001 20:21:53 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: 7.2 RPMs
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

Mon, 17 Sep 2001 14:23:05 -0400
Lamar Owen <lamar.owen@wgcr.org>
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.

17 Sep 2001 15:02:36 -0400
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: 7.2 RPMs
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

Mon, 17 Sep 2001 16:48:56 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: 7.2 RPMs
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


Mon, 17 Sep 2001 23:36:53 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: 7.2 RPMs
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.

17 Sep 2001 17:40:01 -0400
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: 7.2 RPMs
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


Mon, 17 Sep 2001 23:44:10 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: 7.2 RPMs
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

Mon, 17 Sep 2001 17:52:00 -0400
Lamar Owen <lamar.owen@wgcr.org>
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

Mon, 17 Sep 2001 18:18:13 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: 7.2 RPMs