Re: 7.1 RPMs - Mailing list pgsql-hackers

> I haven't addressed that as yet.  Is it safe to assume that -ffast-math
> should be Considered Harmful in the RPM_OPT_FLAGS?  Is -ffast-math
> _ever_ a Good Thing for our routines?  I can easily enough strip out
> -ffast-math from the flags for all cases (xarg -n 1 grep -v
> ffast-math|xargs is your friend....).

I believe that there is no room for -ffast-math in PostgreSQL. The
compiler man page says that the option allows the compiler to generate
code which does not conform to IEEE math standards, and istm that we
might consider that as affecting our predictability and portability. The
man page also warns against using -ffast-math and -O together, but I
can't tell if that is a warning to users or a "note to myself" for the
compiler maintainers.

> While I don't plan on following the Mandrake Way WRT repackaging our
> tarball with bzip2, the source RPM should use whatever compression for
> the man pages that the buildrootpolicy for that distribution supplies.

Certainly so for the tarball. However the tarballs are delivered is how
we should use them imho. Why is it an issue for the man pages? They are
uncompressed in our source tarball (? haven't checked) and if we have
them uncompressed in the RPM build area then they get compressed by RPM
somewhere between installation and RPM packaging, right?

> > How are you planning on packaging the hardcopy docs? They are not yet
> > available, but will be Real Soon Now :(
> In the postgresql-docs subpackage, along with the SGML source.  The html
> built docs made from the SGML source is still going into the main
> tarball, as they are nice and browseable in their standard location.
> If I release a -1 RPM without the hardcopy, I can release a -2 with....

Great.

> There's also a question about the Python client -- it would be good if
> someone who has downloaded one of the RC RPM's could test that, as I'm
> not a snake charmer. :-)

Not sure about the python stuff, and I don't recall doing anything in
the past on that topic.

> Also, I need either a standard way to build the java stuff (meaning my
> own JDK that is reasonably standard by consensus -- kaffe ships with
> RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to
> package 7.1 JDBC jars for my packaging pleasure.  I'm running low enough
> on disk space on my devel machines (one of which is a notebook) to make
> my own JDK a second choice.

In the past I have found that kaffe did not handle enough java code for
my needs, but that was not for the JDBC driver. I am currently using
jikes for my projects, and it produces *nice* code in my experience.
                    - Thomas