Re: new PostgreSQL
Alex Yukhimets wrote:
>Hi.
>
>I read recent proposition of the maintainer about conflicting with previous
>version and remark that package has to be renamed to do that.
>I don't like that renaming thing after each, even non-major version.
No, I don't either.
>I have another proposition: Do not make package conflict with previous
>version, let dselect upgrade it, but stop the server and do NOT restart
>it. Display a notice that in order to make old database work, sys admin
>should follow instructions in /usr/doc/postgresql/Readme.uprgade and
>modify /etc/init.d/postgresql. In the latter, you just put short
>instructions and reference to that Readme and "exit 0" before the
>start-stop script itself, with a notice to remove this "exit 0" after
>data is dumped and restored.
>
>How about it?
I like it in theory, but will it actually work? What is the actual sequence
of events when dpkg does an upgrade of a package?
In order to dump the old database, the old binaries (postmaster, postgres,
psql and the shared library libpq.so) must be used with the
new pg_dumpall script; if the binaries still exist, the preinst script of
the new version can move them somewhere to keep them safe. But will they
still exist? or will they already have been removed? Does dpkg simply
overwrite them, or does it delete the old version's files before installing
the new one?
Thank you for your suggestion; if it works it will be a better way of
managing the upgrade than any I had yet thought of.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@debian.org .
Reply to: