Re: postgresql-6.5.3 (potato): Re: First Test Cycle starts today
I agree with those who have said that this is really an issue with
PostgreSQL rather than with Debian. The upstream model is that databases
should be reduced to some sort of canonical storage, such as a flat dump,
and then reimported into the new format using the new binaries.
If it is any consolation, I have doubts that there are any serious users
of PostgreSQL still on slink. In fact, PostgreSQL was (along with the
JDK) the main reason we decided to move to potato for production well
ahead of formal release. There are such major differences between
PostgreSQL 6.3 and 6.5 that we absolutely had to have the new version.
Despite this, we have been able to stay away from 7.0 so far.
In effect, we already went through the procedure of upgrading from slink
to potato that you are worried about. My view is that, from a Debian
Policy point of view, if the 6.3 binaries are required to do certain tasks
when the 6.5 package is installed, then the 6.3 binaries should be in the
6.5 package. If they get removed and then reinstalled, this will work
despite being inelegant. Another option would be to provide the 6.3
binaries as a special package in potato, rigged so that the files would be
installed where your prerm process puts them. This way, only those who
are upgrading from 6.3 to 6.5 would need to install this package
containing the 6.3 binaries, and those doing a clean install would not.
By contrast, I tend to regard less favorably the indirect approaches which
have been discussed, such as adding hard links.
-- Mike
On 2000-05-02 at 12:57 +0100, Oliver Elphick wrote:
> Richard Braakman wrote:
> >The first official Test Cycle has started today. It's not entirely my
> >doing, but such things gather momentum :-)
>
> Recent experience with people upgrading to woody's postgresql 7.0...
> leads me to expect trouble with the upgrade from slink (6.3.2) to
> (potato) 6.5.3. The trouble is that I can't think what to do about it.
>
> There are two problems; first, that slink is 2 major releases behind
> on postgresql, instead of 1, which may in itself cause upgrading problems,
> and second is the behaviour of apt in handling upgrades.
>
> The first problem is likely to cause some people data problems, which
> may require them to edit their dumped data. I don't think there is
> anything I can do about that. They will just have to live with it.
>
> The second problem is that apt is actually removing packages before
> reinstalling them. Since postgresql relies on picking up the previously
> installed binaries to dump the database during (or after) the upgrade,
> this is disastrous, because apt deletes the necessary binaries before
> postgresql can get to them. I have solved this problem for the
> upgrade from potato to woody by saving the binaries in the prerm, but it
> is not practicable to backport this into slink at this stage.
>
> The end result is that I know there are going to be problems, but I cannot think of any way (inside the packaging system) to handle them. Has
> anyone any suggestions?
Reply to: