Re: [Pkg-postgresql-public] Postgres major version support policy on Debian

Hi!

* Martin Pitt <mpitt(at)debian(dot)org> [2008-10-02 18:12:47 CEST]:
> Markus Wanner [2008-10-02 12:49 +0200]:
> > Unfortunately we are stuck with several Postgres 8.2 installations from
> > etch backports, which are no longer maintained by the backports, because
> > only 8.2 got dropped from testing.
>
> Indeed it was quite clear to me right from the beginning that Lenny
> would ship with 8.3 only. I think from the POV of not supporting
> several PostgreSQL versions in stable Debian releases there is no
> disagreement. Etch is an exception because we needed 7.4 to get an
> upgrade path from Sarge, but further Debian versions will only ever
> support the latest PostgreSQL release.

Alright, so it was actually my own fault to have done the pg-8.2
backports, and I'm sorry for have followed the request to do so. On the
other hand, I still don't fully understand the problems of not being
able to upgrade to pg-8.3 properly. People seem to have been able to
upgrade from 8.1 to 8.2, so what's the real big difference between 8.1
vs. 8.2 and 8.2 vs. 8.3? If it's soo deep, wouldn't that mean that we
are having a general problem with the upgrade path here, too?

> Nevertheless I acknowledge the problem with the existing backport, of
> course. I didn't request the 8.2 one, and personally I don't think it
> is a wise idea to run a production server purely on a backport version
> without being able to upgrade to 8.3 (or spending the necessary work
> to upgrade to newer 8.2 versions, of course), but the world is as it
> is, and people will do that.

Yes, the latter part is what puzzles me personally, too.

> > I'm providing upgraded packages for Postgres 8.2 on my own website [1].
> > There are certainly other people who have run into the same issue, see
> > for example [2] who dislikes using Postgres backports for exactly that
> > reason.

Erm, the referenced mail [2] refers to your own mail, so using that as
a reasoning argument is a bit fishy ... And you failed to outline the
"enough of a reason for an exception" argument you like to brag around
with.

But it's a valid argument to not use something from backports (or any
other repository out there, mind you, it's not limited to backports).
With backports you have a clear ruleset that applies, though.

> > On the backports-users mailing list I've requested that Postgres 8.2
> > gets re-added to etch-backports, with upgraded packages. So that
> > existing installations can get bug- and security fixes for that Postgres
> > versions. One argument for rejection [3] has been, that Postgres 8.2 is
> > not in testing anymore and can thus not be backported. I'm arguing that
> > Postgres 8.2 is a backport per se. Not from testing, but a backport of
> > newer software to etch.

Your argument might be valid, but it doesn't play for backports. It was
always clear that backports.org is about backporting packages from
testing.

> > * Postgres major versions that once got included should continue to be
> > supported and updated within the standard Debian infrastructure as long
> > as supported by the Postgres project itself.

Backports.org is not the standard Debian infrastructure. And even if it
were, you should this rather bring it up e.g. debian-project list.
Having a rule like that would though mean that an ancient version would
never be able to get removed anywhere at all, and would mean that the
postgres project decides what the volunteers within the Debian project
has to do. This doesn't work, and I would be highly surprised if the
PostgreSQL team would actually follow that reasoning, one could argue
the other way round too, and I'm quite sure that the postgresql team
wouldn't be happy to be told by any other project about how and what
they have to do.

> Not my favourite option, but if the postgresql maintenance team would
> actually double in size (IOW, would not just be me), and
> debian-{release,security}@ don't veto, it's ok with me.

If the PostgreSQL project wants to follow that path, they are happily
encouraged to join the Debian packaging team indeed. :)

> > * Postgres major versions dumped from testing, but once added to any
> > backport should be maintained on backports even if it gets dumped from
> > testing.
>
> That would basically lift backports.org to be an officially supported
> Debian archive, which it isn't, and shouldn't be.

By the same rule it could be argued that major version added to testing
should be maintained in testing for as long as can be. It's exactly the
same reasoning, and I guess you can see the pattern here and follow my
rationale outlined above.

> > * Never include Postgres major versions from testing in the backports,
> > as those might get dumped from testing thus support cannot be guaranteed
> > anymore. (Except perhaps when we can be very sure that this won't happen).
>
> That's a viable option. When 8.3 was released, and Lenny's release
> schedule got published (roughly at start of 2008), it was quite sure
> that Lenny will ship with 8.3 only.

That would also mean that you want postgresql 8.3 out of backports.org?
Is this really your approach?

> If that violates the backports.org policy, I'd rather ask them to
> remove the 8.2 backport altogether, since it just doesn't make sense
> any more and just bitrots.

It's already removed from backports, that was the reason that started
this whole discussion. :)

I'm sorry to have done the addition of pg 8.2 initially, and propably
should also be sorry for adding pg 8.3 to backports.org, I thought it
would be a service to the users, but if it seems to cause more headaches
for some people than benefits I propably will have to take the
consequences and refrain from doing the packages for lenny-backports and
do them just for myself privately again.

So long,
Rhonda