Re: PostgreSQL upgrade from slink - proposed solution
"Oliver Elphick" <olly@lfix.co.uk> writes:
> Summary of the problem: postgresql needs to use the binaries of the previous
> release to make a dump of the database, if the old database version is built
> by an earlier release. However, those binaries are no longer available
> by the time postgresql knows they are needed, because apt is likely to
> delete the old package before installing the new one. 6.5.3-18 and later
> handle this by saving the binaries in their prerm. However slink does not
> have this feature, and it is too late to introduce it. This is likely
> to lead to upgrade problems from slink to potato.
And indeed it does.
> Proposed solution: postgresql must depend on a package that contains only
> the old binaries. These will have to be collected for each architecture
> and the package will contain uuencoded versions. This package will
> be called postgresql-slink. In view of library changes from slink to
> potato, I will probably have to build this on a potato system from 6.3.2
> source; alternatively, it will have dependencies on the slink library
> versions (is that feasible?).
I think the library changes don't prevent you from running the earlier
binaries, but building from source is probably a good idea anyway.
Otherwise you can end up with problems of the source for
postgresql-slink not being available. (Presumably this doesn't create
the entire slink installation of postgresql, but just the binaries
necessary to dump the database available for postgresql's postinst to
put into /usr/lib/postgresql/dumpall/6.3.) Also, it's messy to have
binaries in potato that need to be created on a slink machine.
Why not have postresql-slink put its own binaries in
/usr/lib/postgresql/dumpall/6.3? Is there any 6.3 package out there
that presaved the old binaries properly before removing itself? Your
suggestion would appear to be fine, but I'm not sure I understand why
it's necessary.
> The postinst of postgresql will look for binaries presaved by the old
> package. If it does not find them, it will look for a uuencoded version
> from postgresql-slink. If it doesn't find those, it will try to use ones
> copied by the preinst.
If the library changes in potato did make the old binaries unusable,
then this wouldn't be a workable solution, since the presaved binaries
wouldn't work. I think that's not a problem, but I'm not sure.
>
> This expedient will be used only for slink to potato upgrading.
> postgresql 6.5.3-19 will depend on postgresql-slink. postgresql 7.0-final-1
> and later will not.
>
> Comments please.
Reply to: