Subject: Re: PostgreSQL 7.4.1 anyone?
To: None <darcy@NetBSD.org>
From: Greg A. Woods <email@example.com>
Date: 01/13/2004 16:20:39
[ On Tuesday, January 13, 2004 at 06:50:37 (-0500), D'Arcy J.M. Cain wrote: ]
> Subject: Re: PostgreSQL 7.4.1 anyone?
> On January 13, 2004 02:31 am, Greg A. Woods wrote:
> > Yes, but, rhetorically speaking, what are the DBA and SysAdmin together
> > supposed to do when the only option is to erase the existing software
> > and install new software in its place?
> Fix their system so that that isn't the only option. :-)
It's not their problem.
The problem is caused by an un-co-operative PostgreSQL release
management scheme and it's only being corroborated and compounded by
The PostgreSQL distribution should trivially and by default allow for
installation of multiple versions on the same machine without any
conflicts between installed filenames.
If that were to happen then pkgsrc could trivially do the same.
In the mean time having pkgsrc munge the release to make it work that
way is undesirable since it creates what a PostgreSQL user would likely
consider a "non-standard" install.
That leaves us with the choice of either giving up and hoping every
pkgsrc/databases/postgresql user knows how to do all of this by hand; or
else using the safest procedure of doing a dump and reload on every
"Obviously" there would be an "experts" flag that would allow creation
of a binary package (or a direct build and install from source) that
didn't do the dump & reload.
> This is true. In the meantime however, I am willing to manage my systems in
> such a way that I don't need them side by side on the same machine. I still
> need to control when my system goes from 7.3.x to 7.4.x though. I can manage
> it from there.
(A) you are apparently not using pkgsrc to do this change, at least not
in the way that the pkgsrc maintainers envision pkgsrc being used.
(B) I don't think you are representative of the average pkgsrc user.
(BTW, this has absolutely nothing to do with where packages might be
built -- it is all about where they are installed. I.e. binary packages
are where this support must start.)
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>