Re: [COMMITTERS] pgsql: update files for beta3

Log Message:
-----------

update files for beta3

Modified Files:
--------------
pgsql:
configure (r1.570 -> r1.571)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570&r2=1.571)
configure.in (r1.536 -> r1.537)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.536&r2=1.537)
pgsql/doc:
bug.template (r1.44 -> r1.45)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.44&r2=1.45)
pgsql/src/include:
pg_config.h.win32 (r1.45 -> r1.46)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.45&r2=1.46)

scrappy(at)postgresql(dot)org (Marc G. Fournier) writes:
> configure (r1.570 -> r1.571)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570&r2=1.571)

It appears that Marc has got autoconf 2.61 installed now, instead of the
2.59 that we've been using for some time. I'm a bit concerned about the
implications of switching to a version that's got zero track record for
us, and that AFAIK no other committers have installed. I'd rather see
a switch happen at the start of a devel cycle than at beta3; and in any
case it's got to be coordinated so that what is in the release doesn't
vary depending on who committed last.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so
can someone else please run autoconf and commit, and I'll re-tag ...

- --On Thursday, November 15, 2007 23:37:22 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> scrappy(at)postgresql(dot)org (Marc G. Fournier) writes:
>> configure (r1.570 -> r1.571)
>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570
>> &r2=1.571)
>
> It appears that Marc has got autoconf 2.61 installed now, instead of the
> 2.59 that we've been using for some time. I'm a bit concerned about the
> implications of switching to a version that's got zero track record for
> us, and that AFAIK no other committers have installed. I'd rather see
> a switch happen at the start of a devel cycle than at beta3; and in any
> case it's got to be coordinated so that what is in the release doesn't
> vary depending on who committed last.
>
> regards, tom lane

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPSCd4QvfyHIvDvMRApMlAJsFhy+DGsSXMzy6bH0FAEQl11zBKwCfbIQ6
66Upa6SjHDUccKm+Mun/l+g=
=rNQj
-----END PGP SIGNATURE-----

Tom Lane wrote:
> scrappy(at)postgresql(dot)org (Marc G. Fournier) writes:
>> configure (r1.570 -> r1.571)
>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570&r2=1.571)
>
> It appears that Marc has got autoconf 2.61 installed now, instead of the
> 2.59 that we've been using for some time. I'm a bit concerned about the
> implications of switching to a version that's got zero track record for
> us, and that AFAIK no other committers have installed. I'd rather see
> a switch happen at the start of a devel cycle than at beta3; and in any
> case it's got to be coordinated so that what is in the release doesn't
> vary depending on who committed last.

O.k., so what do you want to do? Or more to the point, is there
something I can help with? I have machines with 2.59... Marc do you have
any left with 2.59?

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so
> can someone else please run autoconf and commit, and I'll re-tag ...
>

I can't commit but I can give access to a 2.59 version...

Sincerely,

Joshua D. Drake

> - --On Thursday, November 15, 2007 23:37:22 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>
>> scrappy(at)postgresql(dot)org (Marc G. Fournier) writes:
>>> configure (r1.570 -> r1.571)
>>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570
>>> &r2=1.571)
>> It appears that Marc has got autoconf 2.61 installed now, instead of the
>> 2.59 that we've been using for some time. I'm a bit concerned about the
>> implications of switching to a version that's got zero track record for
>> us, and that AFAIK no other committers have installed. I'd rather see
>> a switch happen at the start of a devel cycle than at beta3; and in any
>> case it's got to be coordinated so that what is in the release doesn't
>> vary depending on who committed last.
>>
>> regards, tom lane
>
>
>
> - ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (FreeBSD)
>
> iD8DBQFHPSCd4QvfyHIvDvMRApMlAJsFhy+DGsSXMzy6bH0FAEQl11zBKwCfbIQ6
> 66Upa6SjHDUccKm+Mun/l+g=
> =rNQj
> -----END PGP SIGNATURE-----
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Thursday, November 15, 2007 20:49:04 -0800 "Joshua D. Drake"
<jd(at)commandprompt(dot)com> wrote:

> Marc G. Fournier wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61,
>> so can someone else please run autoconf and commit, and I'll re-tag ...
>>
>
> I can't commit but I can give access to a 2.59 version...

Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPSIc4QvfyHIvDvMRAoZCAJ9MF5wdAcB0aUTyT8qo62+DF61wywCfQLJF
kSsl+ZTYu9SC+OEuA2NGPfU=
=EDTa
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Thursday, November 15, 2007 20:49:04 -0800 "Joshua D. Drake"
> <jd(at)commandprompt(dot)com> wrote:
>
>> Marc G. Fournier wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61,
>>> so can someone else please run autoconf and commit, and I'll re-tag ...
>>>
>> I can't commit but I can give access to a 2.59 version...
>
> Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...
>

*shrug* :) helping where I can... number is on pmt if you need me :)

Joshua D. Drake

> - ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (FreeBSD)
>
> iD8DBQFHPSIc4QvfyHIvDvMRAoZCAJ9MF5wdAcB0aUTyT8qo62+DF61wywCfQLJF
> kSsl+ZTYu9SC+OEuA2NGPfU=
> =EDTa
> -----END PGP SIGNATURE-----
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> scrappy(at)postgresql(dot)org (Marc G. Fournier) writes:
>> configure (r1.570 -> r1.571)
>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570&r2=1.571)
>
> It appears that Marc has got autoconf 2.61 installed now, instead of the
> 2.59 that we've been using for some time. I'm a bit concerned about the
> implications of switching to a version that's got zero track record for
> us, and that AFAIK no other committers have installed. I'd rather see
> a switch happen at the start of a devel cycle than at beta3; and in any
> case it's got to be coordinated so that what is in the release doesn't
> vary depending on who committed last.

Why is configure even checked in to CVS?

That wouldn't change any of your questions though, it just shifts the point in
the process at which the version of autoconf has to be controlled to the
release tarball creation step rather than when people are checking in changes.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so
> can someone else please run autoconf and commit, and I'll re-tag ...

Done

regards, tom lane

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> <jd(at)commandprompt(dot)com> wrote:
>> I can't commit but I can give access to a 2.59 version...

> Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...

Locally I've got several autoconf versions installed so that I can
update back-branch configure scripts properly. It'd probably be a good
idea to improve your release scripts so that they select the "right"
autoconf version for each release branch. You'll need multiple local
installations though, instead of depending on freebsd ports for the
"one true autoconf".

Either that or we try to move up all supported back branches to the
latest autoconf version; which might be a good idea but it scares me
a bit.

regards, tom lane

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> <jd(at)commandprompt(dot)com> wrote:
>>> I can't commit but I can give access to a 2.59 version...
>
>> Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...
>
> Locally I've got several autoconf versions installed so that I can
> update back-branch configure scripts properly. It'd probably be a good
> idea to improve your release scripts so that they select the "right"
> autoconf version for each release branch. You'll need multiple local
> installations though, instead of depending on freebsd ports for the
> "one true autoconf".
>
> Either that or we try to move up all supported back branches to the
> latest autoconf version; which might be a good idea but it scares me
> a bit.

I say have a VMWare instance running with the "one true" autoconf that
is currently accepted. That way we don't have to make that distinction.
Autoconf 2.59 is going to be predominantly in the wild (rhel 5, centos5
, dapper, debian) for at least another 3-4 years.

Joshua D. Drake

>
> regards, tom lane
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> <jd(at)commandprompt(dot)com> wrote:
>>> I can't commit but I can give access to a 2.59 version...
>
>> Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...
>
> Locally I've got several autoconf versions installed so that I can
> update back-branch configure scripts properly. It'd probably be a good
> idea to improve your release scripts so that they select the "right"
> autoconf version for each release branch. You'll need multiple local
> installations though, instead of depending on freebsd ports for the
> "one true autoconf".
>
> Either that or we try to move up all supported back branches to the
> latest autoconf version; which might be a good idea but it scares me
> a bit.

That would be a good idea, and really simply things ... FreeBSD seems to have
drop'd off support for all but 2.13 and 2.61 ...

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPShG4QvfyHIvDvMRAm48AJ9D7FOT0EyASLJuBmxeLbE+464HdgCg54fJ
xQOk7rf3xBmwEreHKzlk3C4=
=6M0k
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> That would be a good idea, and really simply things ... FreeBSD seems to have
> drop'd off support for all but 2.13 and 2.61 ...

If we do that, (I honestly don't know) what happens on versions that are
running an older version of autoconf? I mean, if everything is put
together with 2.61, are 2.59 versions going to have an issue?

Joshua D. Drake

>
>
> - ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (FreeBSD)
>
> iD8DBQFHPShG4QvfyHIvDvMRAm48AJ9D7FOT0EyASLJuBmxeLbE+464HdgCg54fJ
> xQOk7rf3xBmwEreHKzlk3C4=
> =6M0k
> -----END PGP SIGNATURE-----
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Thursday, November 15, 2007 21:21:59 -0800 "Joshua D. Drake"
<jd(at)commandprompt(dot)com> wrote:

> Marc G. Fournier wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>> That would be a good idea, and really simply things ... FreeBSD seems to
>> have drop'd off support for all but 2.13 and 2.61 ...
>
> If we do that, (I honestly don't know) what happens on versions that are
> running an older version of autoconf? I mean, if everything is put together
> with 2.61, are 2.59 versions going to have an issue?

I believe Tom was suggesting upgrading and testing them to make sure of that
... instead of having 7.3 using one version, 7.4 and 8.0 usnig another, and 8.1
and beyond using a third ... I know right now we have three different versions
'required', just can't recall which fall under which ...

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPSnf4QvfyHIvDvMRAjZSAJ9D28LaQ3abmr6Mb4/vWpwACR602ACgvBP9
18xCapgj6muv2SuYNrLzv+8=
=HvQG
-----END PGP SIGNATURE-----

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> - --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>> Either that or we try to move up all supported back branches to the
>> latest autoconf version; which might be a good idea but it scares me
>> a bit.

> That would be a good idea, and really simply things ... FreeBSD seems to have
> drop'd off support for all but 2.13 and 2.61 ...

Perhaps so, but it'd cost us a fair amount of up-front work to verify
that we don't break the back branches by updating their configure
scripts. Not something I want to touch on a last-minute basis ;-)

[ digs for a moment... ] According to my notes we are using autoconf
2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13
is already out of the picture. It might be that 2.53 to 2.59 to 2.61
is not all that big a jump in reality, but I've got to say that it
scares me when I read commit-log entries that report ten thousand lines
worth of diffs in a 20K-line script ...

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> - --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> wrote:
>>> Either that or we try to move up all supported back branches to the
>>> latest autoconf version; which might be a good idea but it scares me
>>> a bit.
>
>> That would be a good idea, and really simply things ... FreeBSD seems to have
>> drop'd off support for all but 2.13 and 2.61 ...
>
> Perhaps so, but it'd cost us a fair amount of up-front work to verify
> that we don't break the back branches by updating their configure
> scripts. Not something I want to touch on a last-minute basis ;-)

Wasn't suggesting 'last-minute', but maybe post 8.3 release, while things are a
bit quiet?

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPS7E4QvfyHIvDvMRAvgVAKDZ4OlC6dcwIeTu4APXYTfQ6XArlwCdEtBz
ApsX48H6dalG+KJDVy0m+rA=
=RFnE
-----END PGP SIGNATURE-----

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> - --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>> Perhaps so, but it'd cost us a fair amount of up-front work to verify
>> that we don't break the back branches by updating their configure
>> scripts. Not something I want to touch on a last-minute basis ;-)

> Wasn't suggesting 'last-minute', but maybe post 8.3 release, while things are a
> bit quiet?

Sure, if someone wants to do the legwork early in 8.4 devel cycle, I'm
all for it ...

regards, tom lane

Am Freitag, 16. November 2007 schrieb Tom Lane:
> [ digs for a moment... ] According to my notes we are using autoconf
> 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13
> is already out of the picture. It might be that 2.53 to 2.59 to 2.61
> is not all that big a jump in reality, but I've got to say that it
> scares me when I read commit-log entries that report ten thousand lines
> worth of diffs in a 20K-line script ...

Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't
hard at all. We have been doing it for years. (Hint: ./configure; make;
make install)

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

Am Freitag, 16. November 2007 schrieb Marc G. Fournier:
> I know right now we have
> three different versions 'required', just can't recall which fall under
> which ...

You just look into the files to see what was used last time.

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

On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote:
> Am Freitag, 16. November 2007 schrieb Tom Lane:
> > [ digs for a moment... ] According to my notes we are using autoconf
> > 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13
> > is already out of the picture. It might be that 2.53 to 2.59 to 2.61
> > is not all that big a jump in reality, but I've got to say that it
> > scares me when I read commit-log entries that report ten thousand lines
> > worth of diffs in a 20K-line script ...
>
> Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't
> hard at all. We have been doing it for years. (Hint: ./configure; make;
> make install)

Yeah.

I reiterate my point that I think it'd be good with a dedicated VM to build
the snapshots and releases off, that isn't affected by other changes to
whatever machine happens to be used. This VM could then be given all the
required autoconf versions, and it'd stay stable - and wouldn't be affected
by choices by whatever distribution is used.

Last time it was flex (or was it bison). This time autoconf (which I
beleive has happened before as well). It *will* happen again. If we move to
the latest autoconf now, it will just happen the next time <distro of
choice> upgrades what they have. (I say distro of choice. In thi case it's
freebsd, but I'm sure it happens on other platforms as well. For example, I
notice my Gutsy box has a different autoconf from my Dapper one. Which is
why I do my pg autoconf work on the dapper one)

//Magnus

"Magnus Hagander" <magnus(at)hagander(dot)net> writes:

> On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote:
>> Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't
>> hard at all. We have been doing it for years. (Hint: ./configure; make;
>> make install)
>
> Yeah.
>
> I reiterate my point that I think it'd be good with a dedicated VM to build
> the snapshots and releases off, that isn't affected by other changes to
> whatever machine happens to be used. This VM could then be given all the
> required autoconf versions, and it'd stay stable - and wouldn't be affected
> by choices by whatever distribution is used.

That would work for flex and bison but we're (inexplicably afaict) *checking
in* the autoconf output into CVS. So it isn't the version of autoconf used to
cut the release which matters, it's the last version anyone used to run
autoconf.

I guess part of Marc's release cutting routine is to rerun autoconf and check
in that result? But that's arguably even worse. It means that after having
tested the source with whatever version of autoconf the last configure.in
hacker used for months we suddenly switch to whatever Marc's machine generates
just before release. Of course having every developer run autoconf suffers
from that problem too.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

Am Freitag, 16. November 2007 schrieb Magnus Hagander:
> Last time it was flex (or was it bison). This time autoconf (which I
> beleive has happened before as well). It *will* happen again.

Just download autoconf, bison, flex from GNU and do a source install. That
should cover the problem.

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

On Fri, Nov 16, 2007 at 10:32:13AM +0100, Peter Eisentraut wrote:
> Am Freitag, 16. November 2007 schrieb Magnus Hagander:
> > Last time it was flex (or was it bison). This time autoconf (which I
> > beleive has happened before as well). It *will* happen again.
>
> Just download autoconf, bison, flex from GNU and do a source install. That
> should cover the problem.

Yes. It's easy to do. But unless we want to get bitten by this again, it
has to live in a controlled environment.
IMHO, of course ;-)

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> I reiterate my point that I think it'd be good with a dedicated VM to build
> the snapshots and releases off, that isn't affected by other changes to
> whatever machine happens to be used. This VM could then be given all the
> required autoconf versions, and it'd stay stable - and wouldn't be affected
> by choices by whatever distribution is used.

That's really not the worst part of the problem. The worst part is that
all developers who ever touch the configure script need to have the same
autoconf version installed, and when dealing with back branches need to
remember to use the right version. So I think focusing on only the
environment used for tarball-building misses the point. We need a
solution targeted at all-developers-including-Marc, not one that just
sets the release process in stone.

One idea people might suggest is to stop keeping the generated configure
script in CVS. I'm not sure that'd make things better though. We'd be
buying into the concept of trying to make configure.in work with any
autoconf version any developer might be likely to use. I'm really not
too sure what the functional incompatibilities between versions are,
but given the extent of line-by-line diffs I've seen in the output of
even adjacent versions, this isn't a question I want to take lightly.

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> I reiterate my point that I think it'd be good with a dedicated VM to build
>> the snapshots and releases off, that isn't affected by other changes to
>> whatever machine happens to be used. This VM could then be given all the
>> required autoconf versions, and it'd stay stable - and wouldn't be affected
>> by choices by whatever distribution is used.
>
> That's really not the worst part of the problem. The worst part is that
> all developers who ever touch the configure script need to have the same
> autoconf version installed, and when dealing with back branches need to
> remember to use the right version. So I think focusing on only the
> environment used for tarball-building misses the point. We need a
> solution targeted at all-developers-including-Marc, not one that just
> sets the release process in stone.

So let's create a VM for just this? A VM is very cheap, it just costs a
bit of disk space as long as it's not used. And give committers access
to it, to use it for committing these changes (unless they are running
the correct version at home - a simple cvs diff before committing should
show you very clearly if you're not).

And before it's suggested, this should not be the cvs VM. The cvs VM is
a dedicated VM for just that for stability and security reasons. It
should remain that. Even though it's a VM where all the devs have
accounts already.

> One idea people might suggest is to stop keeping the generated configure
> script in CVS. I'm not sure that'd make things better though. We'd be
> buying into the concept of trying to make configure.in work with any
> autoconf version any developer might be likely to use. I'm really not
> too sure what the functional incompatibilities between versions are,
> but given the extent of line-by-line diffs I've seen in the output of
> even adjacent versions, this isn't a question I want to take lightly.

Having it in cvs made life a *lot* easier when developing with mingw.
Getting the proper autoconfy stuff going there is not easy at all. I'm
sure there can be others having the same problems.

I would much prefer a solution that keeps it in cvs.

//Magnus

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > I reiterate my point that I think it'd be good with a dedicated VM to build
> > the snapshots and releases off, that isn't affected by other changes to
> > whatever machine happens to be used. This VM could then be given all the
> > required autoconf versions, and it'd stay stable - and wouldn't be affected
> > by choices by whatever distribution is used.
>
> That's really not the worst part of the problem. The worst part is that
> all developers who ever touch the configure script need to have the same
> autoconf version installed, and when dealing with back branches need to
> remember to use the right version. So I think focusing on only the
> environment used for tarball-building misses the point. We need a
> solution targeted at all-developers-including-Marc, not one that just
> sets the release process in stone.
>
> One idea people might suggest is to stop keeping the generated configure
> script in CVS. I'm not sure that'd make things better though. We'd be
> buying into the concept of trying to make configure.in work with any
> autoconf version any developer might be likely to use. I'm really not
> too sure what the functional incompatibilities between versions are,
> but given the extent of line-by-line diffs I've seen in the output of
> even adjacent versions, this isn't a question I want to take lightly.

Could we compare the configure version used during the compile and throw
an error to catch mismatches? You would have to hard-code the configure
version into one of the static Makefiles.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> I'm really not
> too sure what the functional incompatibilities between versions are,
> but given the extent of line-by-line diffs I've seen in the output of
> even adjacent versions, this isn't a question I want to take lightly.

Just curious, but isn't that something the buildfarm would be good for?
generate/commit a 6.1 version of configure, and see if any of hte buildfarm
environments break ... or am I missing something 'post-install' that could be
affected?

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPdXm4QvfyHIvDvMRAsuEAJwJ4F5yISz8wa/AR9W/b2kwgEky/ACgh015
7KGhYRO3GoyT/M/2mJn9k24=
=2/7/
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>
>> I'm really not
>> too sure what the functional incompatibilities between versions are,
>> but given the extent of line-by-line diffs I've seen in the output of
>> even adjacent versions, this isn't a question I want to take lightly.
>
> Just curious, but isn't that something the buildfarm would be good for?
> generate/commit a 6.1 version of configure, and see if any of hte buildfarm
> environments break ... or am I missing something 'post-install' that could be
> affected?

Maybe the BF members could just run their default autoconf as part of
the build if they have one.

/D

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, November 16, 2007 17:44:52 +0000 Dave Page <dpage(at)postgresql(dot)org>
wrote:

> Marc G. Fournier wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> wrote:
>>
>>> I'm really not
>>> too sure what the functional incompatibilities between versions are,
>>> but given the extent of line-by-line diffs I've seen in the output of
>>> even adjacent versions, this isn't a question I want to take lightly.
>>
>> Just curious, but isn't that something the buildfarm would be good for?
>> generate/commit a 6.1 version of configure, and see if any of hte buildfarm
>> environments break ... or am I missing something 'post-install' that could
>> be affected?
>
> Maybe the BF members could just run their default autoconf as part of the
> build if they have one.

you lost me on that one ... Tom is hestitant about moving to 6.1 because we
don't know what the fall out will be ... since I imagine the fallout would be
in the configure/build stage, if we modified CVS to have a 6.1 configure script
in place, wouldn't the buildfarm servers not be a good means to test *if* there
is any fallout?

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPdjx4QvfyHIvDvMRAj6AAJwO7SFyhCi0qdFANX/5pWt8dagWFACff82K
NbrLYsQF9JKIerV4DxPoljU=
=gvyw
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
>> Maybe the BF members could just run their default autoconf as part of the
>> build if they have one.
>
> you lost me on that one ... Tom is hestitant about moving to 6.1 because we
> don't know what the fall out will be ... since I imagine the fallout would be
> in the configure/build stage, if we modified CVS to have a 6.1 configure script
> in place, wouldn't the buildfarm servers not be a good means to test *if* there
> is any fallout?

If the first thing some of them do is re-run autoconf, then we should
get test results for a variety of versions as found on various distros.
We would then be able to tell which versions may or may not work which
could help us when we need to upgrade, or if someone has problems with a
specific version when hacking (which should be rare I appreciate).

/D

Magnus Hagander wrote:
> Tom Lane wrote:
>
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>
>>> I reiterate my point that I think it'd be good with a dedicated VM to build
>>> the snapshots and releases off, that isn't affected by other changes to
>>> whatever machine happens to be used. This VM could then be given all the
>>> required autoconf versions, and it'd stay stable - and wouldn't be affected
>>> by choices by whatever distribution is used.
>>>
>> That's really not the worst part of the problem. The worst part is that
>> all developers who ever touch the configure script need to have the same
>> autoconf version installed, and when dealing with back branches need to
>> remember to use the right version. So I think focusing on only the
>> environment used for tarball-building misses the point. We need a
>> solution targeted at all-developers-including-Marc, not one that just
>> sets the release process in stone.
>>
>
> So let's create a VM for just this? A VM is very cheap, it just costs a
> bit of disk space as long as it's not used. And give committers access
> to it, to use it for committing these changes (unless they are running
> the correct version at home - a simple cvs diff before committing should
> show you very clearly if you're not).
>
> And before it's suggested, this should not be the cvs VM. The cvs VM is
> a dedicated VM for just that for stability and security reasons. It
> should remain that. Even though it's a VM where all the devs have
> accounts already.
>
>

I just don't see any great value in it. I keep trees for doing commit
work on all branches on my workstation - I suspect most other committers
do too. I'm going to want the relevant configure version where I do my
work, so I can test things out. Having multiple versions around isn't a
huge burden.

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, November 16, 2007 18:00:26 +0000 Dave Page <dpage(at)postgresql(dot)org>
wrote:

> Marc G. Fournier wrote:
>>> Maybe the BF members could just run their default autoconf as part of the
>>> build if they have one.
>>
>> you lost me on that one ... Tom is hestitant about moving to 6.1 because we
>> don't know what the fall out will be ... since I imagine the fallout would
>> be in the configure/build stage, if we modified CVS to have a 6.1 configure
>> script in place, wouldn't the buildfarm servers not be a good means to test
>> *if* there is any fallout?
>
> If the first thing some of them do is re-run autoconf, then we should get
> test results for a variety of versions as found on various distros. We would
> then be able to tell which versions may or may not work which could help us
> when we need to upgrade, or if someone has problems with a specific version
> when hacking (which should be rare I appreciate).

Ah, okay, you are going for the 'remove pre-built configure from cvs' route ..
that works too, and does make sense ... wouldn't definitely make sure we get
broad coverage ...

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHPdwq4QvfyHIvDvMRAiqvAKDdtV+AtsFZe9WkbG+7GYPRs+0zvQCeJGxX
pY3WUGVHUgXtU1mfYIGAfBo=
=wyE3
-----END PGP SIGNATURE-----

Dave Page wrote:
>>
>>
>> Just curious, but isn't that something the buildfarm would be good
>> for? generate/commit a 6.1 version of configure, and see if any of
>> hte buildfarm environments break ... or am I missing something
>> 'post-install' that could be affected?
>
> Maybe the BF members could just run their default autoconf as part of
> the build if they have one.
>

We are making a mountain out of a molehill here. We've managed to get
this right for years with very little fuss. Why make infrastructure to
handle a problem that is at most marginal? I have more pressing concerns
that building an autoconf step into buildfarm.

(And I share Tom's concern about version compatibility - the autoconf
team don't have a great record on that IIRC.)

cheers

andrew

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Friday, November 16, 2007 18:00:26 +0000 Dave Page <dpage(at)postgresql(dot)org>
> wrote:
>
>> Marc G. Fournier wrote:
>>>> Maybe the BF members could just run their default autoconf as part of the
>>>> build if they have one.
>>> you lost me on that one ... Tom is hestitant about moving to 6.1 because we
>>> don't know what the fall out will be ... since I imagine the fallout would
>>> be in the configure/build stage, if we modified CVS to have a 6.1 configure
>>> script in place, wouldn't the buildfarm servers not be a good means to test
>>> *if* there is any fallout?
>> If the first thing some of them do is re-run autoconf, then we should get
>> test results for a variety of versions as found on various distros. We would
>> then be able to tell which versions may or may not work which could help us
>> when we need to upgrade, or if someone has problems with a specific version
>> when hacking (which should be rare I appreciate).
>
> Ah, okay, you are going for the 'remove pre-built configure from cvs' route ..
> that works too, and does make sense ... wouldn't definitely make sure we get
> broad coverage ...

No, I wouldn't remove it - leave it there for some BF members, but have
others regenerate it just for test purposes.

/D

Andrew Dunstan wrote:
> (And I share Tom's concern about version compatibility - the autoconf
> team don't have a great record on that IIRC.)

Thats why I think it might be useful to keep an eye on what does and
doesn't work.

I agree it's not a major issue though, so if it's non-trivial to
implement then there's no point persuing the idea.

/D

Magnus Hagander wrote:
> So let's create a VM for just this?

This just moves the problem elsewhere: from "use the right autoconf version"
to "use the right VM".

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

Dave Page wrote:
> Maybe the BF members could just run their default autoconf as part of
> the build if they have one.

The problem here isn't really that we require a great testing and staging
procedure for introducing new autoconf versions. The issue at hand is
strictly that we shouldn't introduce a new autoconf version at the night of
beta 3.

When we want to move to a newer autoconf, we can handle it like any other
patch.

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

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> We are making a mountain out of a molehill here. We've managed to get
> this right for years with very little fuss. Why make infrastructure to
> handle a problem that is at most marginal? I have more pressing concerns
> that building an autoconf step into buildfarm.

I think that trying to get configure.in to work with arbitrary versions
of autoconf is probably not a very useful expenditure of time, anyway.

What we *do* need is some way of checking whether the right autoconf
version was used in any particular branch; right now we simply rely on
committers to get it right, and it's an easy thing to mess up.

Bruce's suggestion of somehow checking this in the top Makefile is
a possibility, but even better would be if creating configure from
configure.in failed outright. We have an AC_PREREQ in there that
fails if autoconf is too old, but can we tighten it to also complain
if too new?

regards, tom lane

Tom Lane wrote:
> Bruce's suggestion of somehow checking this in the top Makefile is
> a possibility, but even better would be if creating configure from
> configure.in failed outright. We have an AC_PREREQ in there that
> fails if autoconf is too old, but can we tighten it to also complain
> if too new?

Yes:

diff -ur ../cvs-pgsql/configure.in ./configure.in
--- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.000000000 +0100
+++ ./configure.in 2007-11-16 22:27:36.000000000 +0100
@@ -19,7 +19,7 @@

AC_INIT([PostgreSQL], [8.3beta3], [pgsql-bugs(at)postgresql(dot)org])

-AC_PREREQ(2.59)
+m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])])
AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group])
AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
AC_CONFIG_AUX_DIR(config)

This appears to work with 2.53, 2.59, and 2.61, which are the ones that
affect us at the moment. I can backpatch this all the way to 7.3 if desired.

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

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> Bruce's suggestion of somehow checking this in the top Makefile is
>> a possibility, but even better would be if creating configure from
>> configure.in failed outright. We have an AC_PREREQ in there that
>> fails if autoconf is too old, but can we tighten it to also complain
>> if too new?

> Yes:

Excellent.

> This appears to work with 2.53, 2.59, and 2.61, which are the ones that
> affect us at the moment. I can backpatch this all the way to 7.3 if desired.

Please.

regards, tom lane

Gregory Stark wrote:
> Why is configure even checked in to CVS?
>
>
>

Right now you don't even need autoconf installed to build out of CVS. Do
we want to impose that as an extra requirement? And if we did it would
need to be the same one used to cut tarballs, or one provably compatible.

cheers

andrew

Peter, were you going to address this?

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Tom Lane wrote:
> > Bruce's suggestion of somehow checking this in the top Makefile is
> > a possibility, but even better would be if creating configure from
> > configure.in failed outright. We have an AC_PREREQ in there that
> > fails if autoconf is too old, but can we tighten it to also complain
> > if too new?
>
> Yes:
>
> diff -ur ../cvs-pgsql/configure.in ./configure.in
> --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.000000000 +0100
> +++ ./configure.in 2007-11-16 22:27:36.000000000 +0100
> @@ -19,7 +19,7 @@
>
> AC_INIT([PostgreSQL], [8.3beta3], [pgsql-bugs(at)postgresql(dot)org])
>
> -AC_PREREQ(2.59)
> +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])])
> AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group])
> AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
> AC_CONFIG_AUX_DIR(config)
>
> This appears to work with 2.53, 2.59, and 2.61, which are the ones that
> affect us at the moment. I can backpatch this all the way to 7.3 if desired.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Am Samstag, 24. November 2007 schrieb Bruce Momjian:
> Peter, were you going to address this?

It's done now.

> > diff -ur ../cvs-pgsql/configure.in ./configure.in
> > --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.000000000 +0100
> > +++ ./configure.in 2007-11-16 22:27:36.000000000 +0100
> > @@ -19,7 +19,7 @@
> >
> > AC_INIT([PostgreSQL], [8.3beta3], [pgsql-bugs(at)postgresql(dot)org])
> >
> > -AC_PREREQ(2.59)
> > +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf
> > version 2.59 is required])]) AC_COPYRIGHT([Copyright (c) 1996-2007,
> > PostgreSQL Global Development Group])
> > AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
> > AC_CONFIG_AUX_DIR(config)

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