On Tuesday 17 September 2002 03:59 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > as yet. I would expect to be able to release an RPMset for beta 2 if
> > that is a week or two off.
> Given that we'll be forcing an initdb for beta2 anyway, those who use
> RPMs may be just as happy to have missed beta1.
Hmmm. Any idea if any more initdb forcings are going to happen? :-)
> > I am waiting the result of the pg_dump from 7.2.x to 7.3 restore
> > discussion.
> Right. We clearly have to support loading of 7.2 dumps; the only issue
> in my mind is exactly how we kluge that up ;-). I just talked to Bruce
> about this a little bit, and we came to the conclusion that there are
> two plausible-looking paths:
> Comments?
From a user/packager viewpoint: the exact mechanics on the internal level,
while nice to know (so that I know what to look for in bug reports), are
rather irrelevant when it comes to 'how do I package?'. What I am looking
at is whether the user will have to run 7.3's pg_dump in order to migrate
older data. If so I, and Oliver, will have to kludge up dependencies and
linkages in ways that I'm not happy with, but can do if need be. And
migration is 'need be' if ever there were 'need be'.
I think that I will be able to just build a 'postgresql-olddump' package or
similar that contains 7.3's pg_dump in a 7.2.2-friendly form, and let the
various distributors worry about building that for older system libraries.
:-) This is just a possibility -- it may not be nearly as hard as I fear it
will be -- best case is I do virtually nothing and let people upgrade the
postgresql-libs and the main package (which includes pg_dump anyway), leaving
the existing postgresql-server package in place. They then dump, erase the
old server package, and install the new server package. I have disabled rpm
upgrades for the server subpackage as of 7.2.2, so that portion I know is
doable. I'll just have to try it. I may be overanalyzing the situation. :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
