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

[Markus Wanner]

Hi,

Gerfried Fuchs wrote:
>  I see your point and don't object to it in principle. It's just that
> manpower is lacking, including being able to do upstream work on the
> packages when upstream cease their support on it.

Please note, that with Dimitri and me, there are already two people
offering help with packaging and supporting older major version releases
of Postgres for Debian.

>  The policy for packages in stable is that the maintainers believe that
> they will last for the lifetime of the stable release. This isn't the
> case here.

Most OSS projects don't provide any kind of guarantee or best-effort
promise WRT long time support, let alone an end of life date. I'm
guessing here, but I'd say that at least 90% of all Debian packages are
not backed by such a promise (including the Linux kernel itself, IIRC).

Considering the very good track record of Postgres WRT stability and
long time support, it seems unfair to measure Postgres by those EOL
dates while accepting a good enough probability for other projects, most
of which are smaller and/or don't have a fraction of the support from
developers and companies that Postgres has.

Thus my (as-modest-as-possible) proposal: please allow us to (help to)
ship all of the Postgres major releases back to (but excluding) the one
shipped with the last Debian stable.

For example, lenny ships with postgresql-8.3, according to this
proposal, it would also have provided postgresql-8.2, but not
postgresql-8.1 (which is in etch). Squeeze should ship with
postgresql-8.4 as well as postgresql-8.5, maybe even postgresql-8.6, if
upstream releases that before Debian Squeeze is released.

Such a release policy for Postgres would make more of the well
maintained major releases of Postgres available for Debian users. Using
Debian oldstable and stable repositories together, users could access
and easily install around four or five major release versions (depending
on release dates) and keep them installed in parallel.

Some minor notes regarding that issue:

 * an upgrade between Postgres major versions normally requires a time
and (disk-)space consuming dump/restore cycle, which users often want to
avoid (except with the upcoming pg_migrator, see below). Thus lots of
users are still running pretty old major versions (and that's why the
upstream project supports several major versions in parallel). Upgrading
the underlying hardware and/or operating system often is much less
troublesome.

 * with postgresql-common, the framework to install and run multiple
major versions of Postgres in parallel is already there, thanks to
Martin Pitt. (And unlike any RPM distro out there).

 * pg_migrator only supports upgrading one major versions at a time, to
upgrade from 8.3 to 8.5, you'll (most probably) need to go via 8.4. A
direct upgrade path from 8.3 to 8.5 doesn't exist (despite the full dump
/restore cycle)

 * backports would not have to drop support for any major version, just
because it got dropped in testing.

 * I can't think of a single user, who'd expect Debian to keep
maintaining Postgres major versions that are marked obsolete upstream.
(While I know some who consciously run an EOL'd versions). No other
Debian component relies on Postgres to work (unlike the kernel, for
example). So I don't see any problem in dropping support for major
versions that are EOL'd upstream during the oldstable phase (and given
the current release frequency, it's highly unlikely for any major
version to hit EOL while being in Debian stable, with the proposed policy).

For these reasons, please stop penalize Postgres for providing EOL dates
and rather pass on these seldom pieces of very mature OSS software to
your users.

Regards

Markus Wanner