Beta2 ... ?

Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?

I'll commit small changes to xlog.c today.

Vadim

The Hermit Hacker <scrappy@hub.org> writes:

Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?

Wrap it up, I'd say. I don't have anything pending that seems worth
holding up beta2 for.

regards, tom lane

mike wrote:

Tom Lane Wrote:

Wrap it up, I'd say. I don't have anything pending that seems worth
holding up beta2 for.

Will RPM's be made availiable for this beta release?

I intend to do so, but it will be a few days to a week after the tarball
release.

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

Ok, consider my mind changed. :-). My only concerns were, due to some
feedback I have gotten, is that people would treat the RPM release as
_productions_ rather than beta -- but maybe I'm just being paranoid.
More than likely I'm being paranoid.....

Look for RPM's in a few days, then.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

Ok, consider my mind changed. :-). My only concerns were, due to some
feedback I have gotten, is that people would treat the RPM release as
_productions_ rather than beta -- but maybe I'm just being paranoid.

As long as the RPMs are clearly marked beta, I don't have a lot of
sympathy for anyone who thinks beta == production.

regards, tom lane

The Hermit Hacker <scrappy@hub.org> writes:

Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?

Wrap it up, I'd say. I don't have anything pending that seems worth
holding up beta2 for.

Will RPM's be made availiable for this beta release?

Mike

The Hermit Hacker writes:

Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?

I'll commit the grammar changes we discussed yesterday, plus some new
documentation that goes with it, tomorrow. I'm also going to send you a
patch for mk-release so that the right documentation files are shipped
this time.

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

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

I'd like to argue for .deb Debian packages as well, for similar reasons.
But I'm aware that those are harder to produce, and that Oliver Elphick
is almost alone on this task.

--
Emmanuel Charpentier

On Fri, 5 Jan 2001, Lamar Owen wrote:

Ok, consider my mind changed. :-). My only concerns were, due to some
feedback I have gotten, is that people would treat the RPM release as
_productions_ rather than beta -- but maybe I'm just being paranoid.

Just because you're paranoid doesn't mean someone isn't out to get you!

But like Tom says - a beta in the name - should do it (and will for me).

Lamar,

Is it possible to put some variables in the spec file so I can turn off
compiling the python and tcl portions. Of course I seem to remember a
thread to a similar effect floating through but can't remember what the
outcome was.

TIA,
Rod
--

Emmanuel Charpentier wrote:

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

I'd like to argue for .deb Debian packages as well, for similar reasons.
But I'm aware that those are harder to produce, and that Oliver Elphick
is almost alone on this task.

I'll be doing it soon; but I don't want to release debs until there is
no more chance of an initdb's being needed between betas; that bit me on
7.0.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Blessed are the pure in heart, for they shall see
God." Matthew 5:8

"Oliver Elphick" <olly@lfix.co.uk> writes:

I'll be doing it soon; but I don't want to release debs until there is
no more chance of an initdb's being needed between betas; that bit me on
7.0.

In that case you may as well say that there will be no beta debs, and
Debian users can forget about being part of the beta test process.

We do not make a guarantee of "no more initdbs" until final release.
The severity of bug needed to make us do one goes up considerably with
each beta, but there will not be a guarantee on *any* beta. If there
were such a guarantee, it'd be final not beta.

regards, tom lane

Oliver Elphick wrote:

Emmanuel Charpentier wrote:

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

I'd like to argue for .deb Debian packages as well, for similar reasons.
But I'm aware that those are harder to produce, and that Oliver Elphick
is almost alone on this task.

I'll be doing it soon; but I don't want to release debs until there is
no more chance of an initdb's being needed between betas; that bit me on
7.0.

Well, it bit me too -- which is one of the lesser reasons why I have
been reluctant to release RPM's before a release candidate. However, if
someone wants to beta test the packaging (which, incidentally, is made
substantially easier with 7.1) of the new release, then they should
expect the results -- for instance, Red Hat doesn't guarantee that you
will be able to upgrade from their public beta test OS releases to any
future release (more than likely you _will_ be able to, but not
necessarily). Only official releases are 'upgradeable'. I would
suggest, as I am doing myself, to release beta-grade packages for
testing _only_, with the proper disclaimers.

But, I don't see how debs are harder to produce than RPMs -- and while I
do have some help from RedHat, SuSE, and others, that help seems to be
more towards their distribution rather than towards PostgreSQL -- ie,
they go their own way for the most part. Each distribution using RPM's
has its own arcane rules -- and some of those rules make little sense
from the PostgreSQL point of view. And, I don't blame them one whit for
that -- they are, after all, employed for the purpose of making a
distribution, not a PostgreSQL package.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Fri, 5 Jan 2001, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed.... :-)

Please do make beta RPMs available. Seems to me that there's a
fair-size population of potential beta testers that we're shutting
out of the process if we don't put out RPMs. Losing available beta
testing work is not a good project management practice ...

FWIW:

We would definately beta test 7.1 beta releases on our test machines if RPMS
were made available. However, if rpms are not made available, its unlikely
that anyone around here will get time to build the sources from scratch. So
you can count me as one beta tester that you would have if you made RPMS of the
betas.

Regards,
Mike

Michael J Schout wrote:

We would definately beta test 7.1 beta releases on our test machines if RPMS
were made available. However, if rpms are not made available, its unlikely
that anyone around here will get time to build the sources from scratch. So
you can count me as one beta tester that you would have if you made RPMS of the
betas.

Your offer is appreciated, and will most definitely be taken :-).

I'm experiencing some degree of difficulty with the build -- mostly due
to some reorg in the Perl and Python clients, but also some main Make
framework as well, thanks to the RPM build-root environment. The
compiles I have done outside the RPM environment have worked and
installed (as source installs) very cleanly -- but the RPM build-root
environment is rather different -- installing files to a location where
they won't actually be installed to :-).

Let me explain: so that RPM builders don't accidentally trash their
systems during building, RPM includes a 'build-root' mechanism that
allows a fake root for the build install to be used instead of the real
root. Think 'chroot-lite'. This build-root is not enforced anywhere
except by the spec file build and install sections. This also allows
RPMs to be built for root installation by a non-root user, which
provides an extra layer of filesystem protection.

So, files get installed to this build-root, for eventual real
installation on the real root when the RPM is actually installed.

However, there are some hard-coded paths left in the build, and the perl
client is being difficult, and odbcinst is going to the REAL /usr/etc
instead of $RPM_BUILD_ROOT/etc.... I have lots of combing to do. In
many ways 7.1 is an easier build -- but not in this regard. But I
consider this an RPM issue and not a PostgreSQL tarball issue, meaning,
while I will be developing patches for the RPM build, I won't expect
those to be integrated into the main tarball.

So, I'm plugging at it....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Michael J Schout writes:

We would definately beta test 7.1 beta releases on our test machines if RPMS
were made available. However, if rpms are not made available, its unlikely
that anyone around here will get time to build the sources from scratch.

Building from source takes five minutes. Reading the installation
instructions takes maybe ten minutes. Don't tell me you don't have that
amount of time but you still want to beta test. *shrug*

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

Lamar Owen writes:

However, there are some hard-coded paths left in the build, and the perl
client is being difficult,

The Perl and Python clients use their own build system. Not sure how to
handle it.

and odbcinst is going to the REAL /usr/etc instead of
$RPM_BUILD_ROOT/etc....

Works here. Hmm, are you using 'make install DESTDIR=/random/place'?
Given that it's not documented it's unlikely that you are. But do start
using it.

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

Peter Eisentraut wrote:

Lamar Owen writes:

However, there are some hard-coded paths left in the build, and the perl
client is being difficult,

The Perl and Python clients use their own build system. Not sure how to
handle it.

I'm looking, in between day job stuff.

and odbcinst is going to the REAL /usr/etc instead of
$RPM_BUILD_ROOT/etc....

Works here.

Which doesn't surprise me. The RPM building environment is not the same
as building from source inside a regular user shell. Similar, but not
the same.

Hmm, are you using 'make install DESTDIR=/random/place'?
Given that it's not documented it's unlikely that you are. But do start
using it.

Enlighten me. DESTDIR does?

Currently, my install lines look like:
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src
install
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C
src/interface
s/perl5 install

So, I would put something like:
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr
DESTDIR=/usr -C src install
???

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

Hmm, are you using 'make install DESTDIR=/random/place'?
Given that it's not documented it's unlikely that you are. But do start
using it.

Enlighten me. DESTDIR does?

It installs files at a different place than where they will eventually
reside. E.g., if your --prefix is /usr/local and DESTDIR=/var/tmp/foo
then the files will end up in /var/tmp/foo/usr/local. This is exactly for
package management type applications.

Currently, my install lines look like:
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src
install
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C
src/interface
s/perl5 install

Then it's not surprising that things don't work since neither POSTGRESDIR
nor PREFIX are used anywhere in PostgreSQL makefiles.

So, I would put something like:
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr
DESTDIR=/usr -C src install
???

./configure --prefix=/usr --sysconfdir=/etc \
--docdir=/usr/share/doc/postgresql-'$(VERSION)' \
--mandir=/usr/share/man \
...other options...
make all
make install DESTDIR=$RPM_BUILD_ROOT

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