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

[Dimitri Fontaine]

Gerfried Fuchs <rhonda at deb.at> writes:
>  Why is it unique to use features only available in a later version?
> That's the whole point of releasing newer versions, so they have newer
> features that one would like to use. I rather would hope that it's
> unique to *not* use newer features, implementing them wouldn't make much
> sense then.

If your new version offers new features based on 8.4 specificities,
all's fine, but you could still #if those in order to still build and
maintain your extension for 8.3. Forcing your users to upgrade to 8.4 in
order to benefit for your bugfixes is strange.

Unless you're maintaining two separate code bases, one for 8.3 and one
for 8.4, which I'm avoiding.

>  This is the whole point of this thread: You won't be able to build and
> run it just fine in Debian because the package won't be there anymore at
> a certain point in time.

The point of this thread is to *change* that, because it's no service to
our users.

>  It shouldn't be big of a deal to script something along that lines for
> automation purposes. Actually, I started with something along that lines
> for wesnoth. It creates the debian/* files from templates that contain
> keyword replacement, including the filename (for your
> debian/foo-8.3.install approaches).

On the other hand I see nothing in the policy forbidding a single binary
package with support (.so, .sql files) for several major versions. Some
python modules already ship with more than one python version .so for
example.

So I'd just do that, but that leaves the debian/control dependencies.

>  Several people have raised points that there actually _is_ value in it,
> and that it is required in certain circumstances. Repeatedly claiming
> otherwise won't get you anywhere.

I beg to differ: debian lacks a deprecation policy for packages in
stable, so that we can ship 8.3 in squeeze and have happy users.

>  That's on a completely different area, and you know that. That's on the
> area of wether the postgres maintenance team is willing to bear the
> burden of shipping more than one major versions of postgres itself and
> has nothing to do with the extensions (only indirect, but you can't run
> an extension for a server that's not there, that's the point).

Please let's ship all currently upstream maintained releases. All the
needed technical support for that is there. We need a policy for
deprecating software in stable, and maybe some more hands to help
packaging. I'm in.

>  The stable users will never have prefix-1.1.0 because that's a new
> upstream version that won't get accepted into stable. If the bug fix is
> relevant enough though it can and should be backported to the 1.0.0
> version from stable where postgres 8.3 is available. There is no need to
> have postgres 8.3 in unstable around for that.

The bugfix is relevant. Not a security bug, but a "can't use it anymore"
bug. Brainfart. As it requires users to rebuild their index, the bugfix
for 1.0.0 calls a version 1.1.0. That's still a bugfix.

Did you read the mail where I explain that PostgreSQL users will *NOT*
want to upgrade their major version at the time they upgrade their
debian release? Why do you insist on letting them out of support?

You do realise that people tend to use debian on production servers
running proprietary software atop the FLOSS stack?

Regards,
-- 
dim