[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze

[Dimitri Fontaine]

Le 28 déc. 2009 à 17:09, Gerfried Fuchs a écrit :
> Why do you claim that Debian doesn't understand that?

There's something simple yet not taken too much into consideration in debian. I know and understand why it is so, and I respect the choice made by Martin Pitt. All the more because I really appreciate the solution he's made for us to use.

The problem is that PostgreSQL is nothing like another software platform as far as upgrades are concerned. Switching from python 2.3 to 2.4 then to 2.5 is far more easy than any PostgreSQL major upgrade. Any time. Even going from PHP4 to PHP5 is easier. Or from Emacs22 to Emacs23. You get the point.

So as a user what you want is *NOT* having to upgrade PostgreSQL at the time you upgrade debian. The fact that a lot of software, debian included, only supports one or two concurrent releases is something that makes them a lot different than PostgreSQL.

What you'd want as a user would be for squeeze to provide (host) PostgreSQL releases 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4, and when the time comes 8.5 through backports. Because that's what upstream put a lot of efforts into maintaining currently.

How it works is not to pick what the distribution has to offer and upgrade when the distribution chooses to upgrade, it's to pick the more recent release your software runs with, or to budget a several months upgrade project in order to be able to switch to something newer.

Now, imagine 7.4 reaches EOL while squeeze had it and is still the current debian stable release. That means debian has to drop that package from its repositories. And that's fine, because that does *NOT* mean, AFAIK, that next apt-get upgrade will remove it and purge the data from your server. It just mean you can not minor-upgrade it anymore, that's what EOL means. Nothing wrong here.

Having all the upstream supported releases available would mean it's now easy to upgrade from anyone to another. Also, please note it's rare to upgrade from a PostgreSQL release to the next, generally you skip one to three releases, sometimes more --- but the user is the only one who knows what the next target is.

Oh, and you know what? I already have production servers running more than one PostgreSQL major release at the same time, and I know other people doing so. Having the debian tools to manage this situation is of a great help, the only drawback there is that the distribution does not default to include all the upstream current releases.

To summarize, I think we're only missing a deprecation policy for PostgreSQL in debian.

Regards,
-- 
dim

PS: my proposal only is/was a workaround to this problem, but if we want to consider what the real problem is instead, that's very fine with me :)

PPS: I don't realize the effort involved into maintaining 5 upstream releases and their minor upgrades, so Martin, if you need help there, just ask.