Обсуждение: pgaccess seems a tad confused
1. Why did the new pgaccess get installed into REL6_5 branch but not
main development branch?
2. New pgaccess no longer has a Makefile in src/bin/pgaccess, which
is a problem because src/bin/Makefile tries to run a sub-make in that
directory when configured --with-tcl. Lack of the sub-Makefile looks
bogus to me; it may not need to do anything for "make all" but it sure
ought to do something for "make install", no?
regards, tom lane
> 1. Why did the new pgaccess get installed into REL6_5 branch but not > main development branch? > No sense putting in development because there will probably be a newer version by the time 6.6 is released, no? > 2. New pgaccess no longer has a Makefile in src/bin/pgaccess, which > is a problem because src/bin/Makefile tries to run a sub-make in that > directory when configured --with-tcl. Lack of the sub-Makefile looks > bogus to me; it may not need to do anything for "make all" but it sure > ought to do something for "make install", no? Yes. I was not in favor of adding new pgaccess in 6.5.2, but was out-voted. I have re-added the Makefile that appeared in the development tree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> 1. Why did the new pgaccess get installed into REL6_5 branch but not > main development branch? > No sense putting in development because there will probably be a newer version by the time 6.6 is released, no? Yes there will be, but it seems to serve two purposes. One is that anyone working with the development tree at least has some version of pgaccess handy. More importantly, though, any bugs in the Makefile or whatever will be noticed early by developers and won't wait until the last moment. Since the basic installation scheme likely doesn't depend much on the exact pgaccess release, there really isn't much to be lost by keeping it in the development tree. Cheers, Brook
> > 1. Why did the new pgaccess get installed into REL6_5 branch but not > > main development branch? > > > > No sense putting in development because there will probably be a newer > version by the time 6.6 is released, no? > > Yes there will be, but it seems to serve two purposes. One is that > anyone working with the development tree at least has some version of > pgaccess handy. More importantly, though, any bugs in the Makefile or > whatever will be noticed early by developers and won't wait until the > last moment. Since the basic installation scheme likely doesn't > depend much on the exact pgaccess release, there really isn't much to > be lost by keeping it in the development tree. It is in the development tree, just not the most recent version. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> More importantly, though, any bugs in the Makefile or
>> whatever will be noticed early by developers and won't wait until the
>> last moment. Since the basic installation scheme likely doesn't
>> depend much on the exact pgaccess release, there really isn't much to
>> be lost by keeping it in the development tree.
> It is in the development tree, just not the most recent version.
But the point is, if the most recent version had been in the development
tree, we'd have had a better shot at noticing that its makefile was
missing...
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> More importantly, though, any bugs in the Makefile or > >> whatever will be noticed early by developers and won't wait until the > >> last moment. Since the basic installation scheme likely doesn't > >> depend much on the exact pgaccess release, there really isn't much to > >> be lost by keeping it in the development tree. > > > It is in the development tree, just not the most recent version. > > But the point is, if the most recent version had been in the development > tree, we'd have had a better shot at noticing that its makefile was > missing... > I guess. The new pgaccess release was so different than the current one, I just cvs removed all files, and readded everything. That is how Makefile go lost. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, 17 Sep 1999, Bruce Momjian wrote:
> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > >> More importantly, though, any bugs in the Makefile or
> > >> whatever will be noticed early by developers and won't wait until the
> > >> last moment. Since the basic installation scheme likely doesn't
> > >> depend much on the exact pgaccess release, there really isn't much to
> > >> be lost by keeping it in the development tree.
> >
> > > It is in the development tree, just not the most recent version.
> >
> > But the point is, if the most recent version had been in the development
> > tree, we'd have had a better shot at noticing that its makefile was
> > missing...
> >
>
> I guess. The new pgaccess release was so different than the current
> one, I just cvs removed all files, and readded everything. That is how
> Makefile go lost.
Ewwww...so, like, we lost the 'history' of the files that only changed vs
were new? *raised eyebrow*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > I guess. The new pgaccess release was so different than the current > > one, I just cvs removed all files, and readded everything. That is how > > Makefile go lost. > > Ewwww...so, like, we lost the 'history' of the files that only changed vs > were new? *raised eyebrow* Yes, thought the pgaccess file was kept I think. I just checked, and somehow the pgaccess files are not in the stable tree anymore, just the directories. I got the final version <24 hours from release. It was in my tree, but now it isn't, and it isn't in 6.5.2 either. I asked for the author to verify my work. I am adding it to the tree now. What do we do? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 20 Sep 1999, Bruce Momjian wrote:
> > > I guess. The new pgaccess release was so different than the current
> > > one, I just cvs removed all files, and readded everything. That is how
> > > Makefile go lost.
> >
> > Ewwww...so, like, we lost the 'history' of the files that only changed vs
> > were new? *raised eyebrow*
>
> Yes, thought the pgaccess file was kept I think. I just checked, and
> somehow the pgaccess files are not in the stable tree anymore, just the
> directories.
>
> I got the final version <24 hours from release. It was in my tree, but
> now it isn't, and it isn't in 6.5.2 either.
>
> I asked for the author to verify my work. I am adding it to the tree
> now. What do we do?
Okay, am very confused here...just did:
cvs checkout -rREL6_5_PATCHES -P pgsql/src/bin/pgaccess
it extracted 243 files...
> cvs status Makefile
===================================================================
File: Makefile Status: Up-to-date
Working revision: 1.1.4.2 Repository revision: 1.1.4.2 /usr/local/cvsroot/pgsql/src/bin/pgaccess/Makefile,v
StickyTag: REL6_5_PATCHES (branch: 1.1.4) Sticky Date: (none) Sticky Options: (none)
I just performed the same on the same on the non-'-r' tree, and now see
what you mean :(
I should be able to fix this momentarily...I hope...
Its all a learning less...assuming you know what you've learnt? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
I am totally confused, but have added the missing files.
> On Mon, 20 Sep 1999, Bruce Momjian wrote:
>
> > > > I guess. The new pgaccess release was so different than the current
> > > > one, I just cvs removed all files, and readded everything. That is how
> > > > Makefile go lost.
> > >
> > > Ewwww...so, like, we lost the 'history' of the files that only changed vs
> > > were new? *raised eyebrow*
> >
> > Yes, thought the pgaccess file was kept I think. I just checked, and
> > somehow the pgaccess files are not in the stable tree anymore, just the
> > directories.
> >
> > I got the final version <24 hours from release. It was in my tree, but
> > now it isn't, and it isn't in 6.5.2 either.
> >
> > I asked for the author to verify my work. I am adding it to the tree
> > now. What do we do?
>
> Okay, am very confused here...just did:
>
> cvs checkout -rREL6_5_PATCHES -P pgsql/src/bin/pgaccess
>
> it extracted 243 files...
>
> > cvs status Makefile
> ===================================================================
> File: Makefile Status: Up-to-date
>
> Working revision: 1.1.4.2
> Repository revision: 1.1.4.2 /usr/local/cvsroot/pgsql/src/bin/pgaccess/Makefile,v
> Sticky Tag: REL6_5_PATCHES (branch: 1.1.4)
> Sticky Date: (none)
> Sticky Options: (none)
>
> I just performed the same on the same on the non-'-r' tree, and now see
> what you mean :(
>
> I should be able to fix this momentarily...I hope...
>
> Its all a learning less...assuming you know what you've learnt? :)
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
On Mon, 20 Sep 1999, Bruce Momjian wrote: > I got the final version <24 hours from release. It was in my tree, but > now it isn't, and it isn't in 6.5.2 either. > > I asked for the author to verify my work. I am adding it to the tree > now. What do we do? Either make a 6.5.3, inline 6.5.2 (6.5.2a, anyone??) or leave 6.5.2 as is. None is ideal -- although a 6.5.3 is better than a badly broken 6.5.2. The short term solution is for those using 6.5.2 to download the pgaccess-0.98 tarball from flex.ro. I ran across the depopulated pgaccess tree this morning while starting the build cycle for the 6.5.2 rpms -- good thing I have already dealt with that issue with previous packages. For the RPM's, it has been practice for some time to include the very latest pgaccess as a separate tarball, then untarring it over top of the one in the main tarball during the package build. I was hoping to get away from that. ;-( ----------------------------------------------------------------------------- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> On Mon, 20 Sep 1999, Bruce Momjian wrote: > > I got the final version <24 hours from release. It was in my tree, but > > now it isn't, and it isn't in 6.5.2 either. > > > > I asked for the author to verify my work. I am adding it to the tree > > now. What do we do? > > Either make a 6.5.3, inline 6.5.2 (6.5.2a, anyone??) or leave 6.5.2 as is. > None is ideal -- although a 6.5.3 is better than a badly broken 6.5.2. The > short term solution is for those using 6.5.2 to download the pgaccess-0.98 > tarball from flex.ro. > > I ran across the depopulated pgaccess tree this morning while starting the > build cycle for the 6.5.2 rpms -- good thing I have already dealt with that > issue with previous packages. For the RPM's, it has been practice for some time > to include the very latest pgaccess as a separate tarball, then untarring it > over top of the one in the main tarball during the package build. I was hoping > to get away from that. ;-( Yes, I have created a bad situation. pgaccess it very important for pgsql. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 20 Sep 1999, Bruce Momjian wrote: > Lamar Owen wrote: > > I ran across the depopulated pgaccess tree this morning while starting the > > build cycle for the 6.5.2 rpms -- good thing I have already dealt with that > > issue with previous packages. For the RPM's, it has been practice for some time > > to include the very latest pgaccess as a separate tarball, then untarring it > > over top of the one in the main tarball during the package build. I was hoping > > to get away from that. ;-( > > Yes, I have created a bad situation. pgaccess it very important for pgsql. I wouldn't have even noticed had I not remembered that pgaccess-0.98 was one of the enhancements in 6.5.2. I was looking to rid the RPM's of the extra tarball of pgaccess. Had I not noticed, I would have blissfully kept the pgaccess-0.98 tarball in the RPM, and not gone rabbit-hunting. As it stands, the pgacess-0.98 tarball is kept in the 6.5.2 RPM, just not blissfully. ;-) Don't punish yourself too hard -- an honest (if avoidable) mistake. ----------------------------------------------------------------------------- Lamar Owen WGCR Internet Radio 1 Peter 4:11