Uploaded.  Please take a look.

ftp://ftp.postgresql.org/pub/dev/test-rpms

There _are_ changes.  I will detail the changes for the RC4 RPMset.

Karl's pl/perl changes will go into the next set.  pg_dumplo will have a
built binary, to be located in /usr/lib/pgsql/contrib.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Sat, 07 Apr 2001 22:41:50 -0400
Lamar Owen <lamar.owen@wgcr.org>
RPMS for RC3
Lamar Owen writes:

> Uploaded.  Please take a look.
>
> ftp://ftp.postgresql.org/pub/dev/test-rpms
>
> There _are_ changes.  I will detail the changes for the RC4 RPMset.

Coupla issues:

I'm confused about the logging.  You install a logrotate configuration
which talks about a file /var/log/postgresql, but the spec file creates a
directory /var/log/pgsql/.  Meanwhile, the start script you provide sends
the log output to /dev/null.

stop() in the init script should use pg_ctl -m fast.

PGVERSION in the init script is still at beta6.  Maybe you should track
this from the source or the spec file.

You're still shipping old jar files.  You could build them from the source
package.

In 'make COPT="$CFLAGS" all', the COPT shouldn't be used.  You should
export CFLAGS before running configure.  (What about CXXFLAGS?)

Before long, 'cp /usr/lib/python1.5/config/Makefile.pre.in .' is going to
get out of date.  There's already Python 1.6 and 2.0.  Since you're
configuring --with-python, the work you do there isn't necessary anyway,
since 'make all' takes care of it.

'make -C doc' is a no-op.  Also, the docs are installed automatically, the
stuff you do under '# man pages....' needs some work.  You probably want
to run gzip on the files after installation.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Mon, 9 Apr 2001 00:30:03 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: RPMS for RC3
Peter Eisentraut wrote:
> Coupla issues:
 
> I'm confused about the logging.  You install a logrotate configuration
> which talks about a file /var/log/postgresql, but the spec file creates a
> directory /var/log/pgsql/

I'll correct that. The logrotate script (which I guess to prevent
confusion should just simply Go Away) was intended to roll a syslog()
log file, after the postinstall scriptlet added a line to
/etc/syslog.conf to place the logs in a good location -- however, as
good solid way of doing that has eluded me at this time -- mostly thanks
to the fact that these RPMs get installed as part of the OS install of
many distributions, meaning I have to carefully choose what utilities I
use during a %pre or %post scriptlet. 

However, I may back down from that position and just document HOW to
setup logging in the README -- these RPMs shouldn't really try to be the
final shipping version for every distribution out there -- they should
just be a good foundation for any distribution that wants to ship
PostgreSQL. The least I can get away with doing, the better.  And the
least I assume, the better.  The current RPMset is far from this ideal,
as there are many RedHatisms that translate poorly to some
distributions.

>.  Meanwhile, the start script you provide sends
> the log output to /dev/null.

Yes.  As statedabout, logging was intended to be completely done via
syslog for ease of rotation as well as consistency withthe target
distribution.
 
> stop() in the init script should use pg_ctl -m fast.

Why?  The stop() may or may not be called as part of system shutdown --
and I have no real way of knowing which.  The system shutdown variety
certainly could use fast -- but the manual variety?  Minor issue,
though.  Might just put the fast in there if there's no good reason not
to.
 
> PGVERSION in the init script is still at beta6.  Maybe you should track
> this from the source or the spec file.

Argh.  Typo.  Yes, a better versioning system is needed. I'll certainly
correct the version before final.  But since I'm getting ready to put
all the RPM's ancilliary files and some build-time scripts into CVS on
greatbridge.org, I'll do a version tracking from the spec file macros
across all scripts as part of that effort.
 
> You're still shipping old jar files.  You could build them from the source
> package.

With which JDK?  As Red Hat doesn't ship a _standard_ JDK, which one is
appropriate? Or, what is the _standard_ JDK?
 
> In 'make COPT="$CFLAGS" all', the COPT shouldn't be used.  You should
> export CFLAGS before running configure.  (What about CXXFLAGS?)

Ok.
 
> Before long, 'cp /usr/lib/python1.5/config/Makefile.pre.in .' is going to
> get out of date.  There's already Python 1.6 and 2.0.  Since you're
> configuring --with-python, the work you do there isn't necessary anyway,
> since 'make all' takes care of it.

Does make all in the python interface properly handle DESTDIR for
correct RPM_BUILD_ROOT handling?  At that point, I'll certainly change
that -- but I had enough trouble with the Perl interface's handling or
mishandling of that -- IOW DESTDIR didn't in the Perl interface
--necessitating three builds of the interface to get it properly linked.
 
> 'make -C doc' is a no-op.

Ok -- now it is, 7.0 it wasn't.  I'll pull it out and see what happens
or doesn't happen.

>  Also, the docs are installed automatically, the
> stuff you do under '# man pages....' needs some work.

The man pages are still in a separate tarball, or not?

>  You probably want
> to run gzip on the files after installation.

Done automagically by the buildrootpolicy of the rpm build system, on
distributions that do buildrootpolicies, which are standard in late
3.0.x RPM as well as 4.x RPM.  This is one of the reasons the %{_mandir}
macro is used for all man pages.

Thanks for taking the time to look (again).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Sun, 08 Apr 2001 20:41:24 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: RPMS for RC3
Lamar Owen writes:

> > You're still shipping old jar files.  You could build them from the source
> > package.
>
> With which JDK?  As Red Hat doesn't ship a _standard_ JDK, which one is
> appropriate? Or, what is the _standard_ JDK?

There is no standard JDK, in the same sense as there is no standard C
compiler.  You run configure --with-java; make; make install and voilï¿½
there's the JDBC driver, made by whatever JDK was around at the moment.
(For appropriate values of voilï¿½, of course.)  Most distributions include
Kaffe I suppose, which should serve fine (once you set up the CLASSPATH
correctly; YMMV).

> The man pages are still in a separate tarball, or not?

They're in a tarball, but they're not separate.

> >  You probably want
> > to run gzip on the files after installation.
>
> Done automagically by the buildrootpolicy of the rpm build system,

Amazing... ;-)

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Mon, 9 Apr 2001 18:44:47 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: RPMS for RC3