Re: RPMS for RC3 - Mailing list pgsql-hackers

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