SRPM for 8.0.0 beta?

Steve Bergman wrote:

Anyone have an SRPM of spec file for the beta?

I just made one; see:
http://www.joeconway.com/postgresql-8.0.0beta1/
There are also Fedora Core 2 binaries there.

One caveat -- I am not the normal package maintainer, so no guarantees ;-).

HTH,

Joe

Steve Bergman wrote:

Anyone have an SRPM of spec file for the beta?

(moved to HACKERS)

I just created and posted a source RPM for 8.0.0beta1. As I'm not the
usual packager, and a pure hack when it comes to building my own RPMs,
it would be a Good Thing(tm) if someone else could vet this package;
available here:
http://www.joeconway.com/postgresql-8.0.0beta1/
There are binaries for Fedora Core 2 there as well.

I think it would help us get wider beta testing if others could build
binaries for other distributions.

Joe

Joe Conway wrote:

Steve Bergman wrote:

Anyone have an SRPM of spec file for the beta?

I just created and posted a source RPM for 8.0.0beta1. As I'm not the
usual packager, and a pure hack when it comes to building my own RPMs,
it would be a Good Thing(tm) if someone else could vet this package;
available here:
http://www.joeconway.com/postgresql-8.0.0beta1/
There are binaries for Fedora Core 2 there as well.

I actually tried to use my own rpm today, and discovered a mistake
resulting in a non-working install. Sorry for that, to those of you who
grabbed a copy.

Version 2 of the source rpm is now available here:
http://www.joeconway.com/postgresql-8.0.0beta1/SRPM/postgresql-8.0.0beta1-2PGDG.src.rpm

I've also put up i386 binary rpms for fc1 and fc2, and x86_64 binary
rpms for fc2.

Joe

Joe Conway wrote:

Version 2 of the source rpm is now available here:
http://www.joeconway.com/postgresql-8.0.0beta1/SRPM/postgresql-8.0.0beta1-2PGDG.src.rpm

I've also put up i386 binary rpms for fc1 and fc2, and x86_64 binary
rpms for fc2.

Hopefully the third try is a charm ;-)

Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb and
start postgres) but not the second and subsequent times.

Joe

Joe Conway <mail@joeconway.com> writes:

Hopefully the third try is a charm ;-)

Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb and
start postgres) but not the second and subsequent times.

[ blink... ] Was this your own error, or are you saying there is such a
bug in the current RPM distributions?

regards, tom lane

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

Hopefully the third try is a charm ;-)

Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb and
start postgres) but not the second and subsequent times.

[ blink... ] Was this your own error, or are you saying there is such a
bug in the current RPM distributions?

My own. I missed changing this line:
if [ `cat $PGDATA/PG_VERSION` != '7.4' ]
to this:
if [ `cat $PGDATA/PG_VERSION` != '8.0' ]

That code section gets skipped over in the case that no initdb has yet
been performed, so I didn't notice until I went to restart the server.

Joe

On Tue, 2004-08-17 at 20:27 -0700, Joe Conway wrote:

My own. I missed changing this line:
if [ `cat $PGDATA/PG_VERSION` != '7.4' ]
to this:
if [ `cat $PGDATA/PG_VERSION` != '8.0' ]

That code section gets skipped over in the case that no initdb has yet
been performed, so I didn't notice until I went to restart the server.

can't it be made version independent?
e.g. something like
if [ -f $PGDATA/PG_VERSION ]
...

--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro

On Tue, Aug 17, 2004 at 08:27:58PM -0700, Joe Conway wrote:

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

Hopefully the third try is a charm ;-)

Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb and
start postgres) but not the second and subsequent times.

[ blink... ] Was this your own error, or are you saying there is such a
bug in the current RPM distributions?

My own. I missed changing this line:
if [ `cat $PGDATA/PG_VERSION` != '7.4' ]
to this:
if [ `cat $PGDATA/PG_VERSION` != '8.0' ]

Isn't there a way to generate this automatically? Why isn't the .spec
file (and the debian directory, for that matter) part of the source
tree?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

Joe Conway wrote:

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

Hopefully the third try is a charm ;-)

Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb
and start postgres) but not the second and subsequent times.

[ blink... ] Was this your own error, or are you saying there is such a
bug in the current RPM distributions?

My own. I missed changing this line:
if [ `cat $PGDATA/PG_VERSION` != '7.4' ]
to this:
if [ `cat $PGDATA/PG_VERSION` != '8.0' ]

BTW I have bitten recently on the attempt of change the default port.
I did it as usual changing it in postgresql.conf but that parameter
is overriden by:
PGPORT=5432
present on the start up script.

There is any reason to still pass this parameter to postmaster ?

Regards
Gaetano Mendola

Alvaro Herrera wrote:

Why isn't the
.spec file (and the debian directory, for that matter) part of the
source tree?

Since packaging usually happens after a release, or at least continues
well after a release, such files or directories would be perpetually
outdated.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

Isn't there a way to generate this automatically? Why isn't the .spec
file (and the debian directory, for that matter) part of the source
tree?

Can't speak for Debian, but Red Hat at least would not use such a spec
file anyway. RH's procedures involve frequent addition of entries to
the spec file's ChangeLog, so they keep package spec files separate from
the "upstream" package tarball. Another good reason for keeping a
separation is that the spec file may represent a package that
aggregates multiple upstream packages. In the PG case a single specfile
currently aggregates the core server, jdbc, and pygresql ... and I'm
getting pressure to include more stuff.

The init script is a different matter. That in principle could be taken
from the upstream package. I'm not sure if all the Linux distributions
could agree on a single init script, though --- I think the conventions
vary somewhat across distros.

regards, tom lane

Gaetano Mendola <mendola@bigfoot.com> writes:

BTW I have bitten recently on the attempt of change the default port.
I did it as usual changing it in postgresql.conf but that parameter
is overriden by:
PGPORT=5432
present on the start up script.

There is any reason to still pass this parameter to postmaster ?

The init script needs to know the port number because it uses it in a
couple places. Set the value you want in
/etc/sysconfig/pgsql/postgresql ...

regards, tom lane

Tom Lane wrote:

Gaetano Mendola <mendola@bigfoot.com> writes:

BTW I have bitten recently on the attempt of change the default port.
I did it as usual changing it in postgresql.conf but that parameter
is overriden by:
PGPORT=5432
present on the start up script.

There is any reason to still pass this parameter to postmaster ?

The init script needs to know the port number because it uses it in a
couple places. Set the value you want in
/etc/sysconfig/pgsql/postgresql ...

I know I know, but I'm wondering if this value could be retrieved from
another place instead:

grep -e "port" /var/lib/pgsql/data/postgresql.conf | cut -d '=' -f 2

I know it's horrible.

May be write some words inside postgresql.conf or write some warning in
the logs for sure could help.

Regards
Gaetano Mendola

Tom Lane wrote:

In the PG case a
single specfile currently aggregates the core server, jdbc, and
pygresql ... and I'm getting pressure to include more stuff.

How does that compute, considering that everyone else appears to be
working on including less stuff?

The init script is a different matter. That in principle could be
taken from the upstream package. I'm not sure if all the Linux
distributions could agree on a single init script, though

That can be answered with a plain and simple "no".

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

In the PG case a
single specfile currently aggregates the core server, jdbc, and
pygresql ... and I'm getting pressure to include more stuff.

How does that compute, considering that everyone else appears to be
working on including less stuff?

Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree. In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set. (In principle I suppose they could be
handled as independent packages with independent specfiles, but so far
the path of least resistance has been to keep 'em bundled together.)

regards, tom lane

Tom Lane wrote:

Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree. In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set. (In principle I suppose they could be
handled as independent packages with independent specfiles, but so far
the path of least resistance has been to keep 'em bundled together.)

On that, note that I specifically removed jdbc and tcl options from the
spec file because the 8.0.0 release notes said they were removed from
the distribution. I suppose at lease jdbc should be put back? It didn't
seem right to include the 7.4 jdbc jars in the 8.0 source rpm, and I
wasn't sure where to get the equivalent of 8.0.0beta1 jdbc jar files (if
such a thing even exists).

Joe

Joe Conway <mail@joeconway.com> writes:

On that, note that I specifically removed jdbc and tcl options from the
spec file because the 8.0.0 release notes said they were removed from
the distribution. I suppose at lease jdbc should be put back? It didn't
seem right to include the 7.4 jdbc jars in the 8.0 source rpm, and I
wasn't sure where to get the equivalent of 8.0.0beta1 jdbc jar files (if
such a thing even exists).

What I've done so far is just to grab the latest stable release from
jdbc.postgresql.org. Using jars as part of the SRPM is pretty ugly,
I agree. There are some other Red Hat folk who have promised to look
into getting JDBC built from source instead, but it's not high priority.

regards, tom lane

Joe Conway wrote:

Tom Lane wrote:

Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree. In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set. (In principle I suppose they could be
handled as independent packages with independent specfiles, but so far
the path of least resistance has been to keep 'em bundled together.)

On that, note that I specifically removed jdbc and tcl options from
the spec file because the 8.0.0 release notes said they were removed
from the distribution. I suppose at lease jdbc should be put back? It
didn't seem right to include the 7.4 jdbc jars in the 8.0 source rpm,
and I wasn't sure where to get the equivalent of 8.0.0beta1 jdbc jar
files (if such a thing even exists).

ISTM we need an S/RPM project on pgfoundry, just like the Windows
installer project. (and maybe a .deb and a Solaris .pkg project too).

cheers

andrew

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

On that, note that I specifically removed jdbc and tcl options from the
spec file because the 8.0.0 release notes said they were removed from
the distribution. I suppose at lease jdbc should be put back? It didn't
seem right to include the 7.4 jdbc jars in the 8.0 source rpm, and I
wasn't sure where to get the equivalent of 8.0.0beta1 jdbc jar files (if
such a thing even exists).

What I've done so far is just to grab the latest stable release from
jdbc.postgresql.org. Using jars as part of the SRPM is pretty ugly,
I agree. There are some other Red Hat folk who have promised to look
into getting JDBC built from source instead, but it's not high priority.

OK, done. Version 4 of the 8.0.0beta1 srpm (and the fc1/fc2 binary rpms)
is available here:
http://www.joeconway.com/postgresql-8.0.0beta1/

Joe