Thread: Re: [ADMIN] SRPM for 8.0.0 beta?
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, 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)
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/
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 <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