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

[Dimitri Fontaine]

Gerfried Fuchs <rhonda at deb.at> writes:
>  Erm, the extensions need only to be available for the same set of
> postgres versions we release. Why do we *need* to have the extensions
> available for postgres versions we never released? If you don't mean
> that, why would you upgrade the extensions then when you don't upgrade
> postgres? I'm sorry but I can't clearly follow you, can you please
> explain this more deeply, maybe with actual examples to ease
> understanding?

Ok that's easy. Really, that's only too easy: I have several PostgreSQL
8.2 in production in debian etch and lenny today.

What happens is that the debian choice of support of major PostgreSQL
version is not followed blindly by users, and given the current
situation in debian, that's for the best. So you pick the upstream
release you're interrested into, either in stable, backports or you
backport it yourself.

And it gets even more complex than that given the recent history of
releases, because 8.2 was in debian etch while it was called testing,
and in backports for sarge. So I got it from there. Then upgraded to
etch, keeping 8.2, which meanwhile had been removed because next stable
would include 8.3.

Now I have a production database running 8.2, that I can't major-upgrade
easily so that will have to wait until later than squeeze-is-stable. And
I want to still install new extensions, such as plproxy, which are
available for postgresql-8.4 only in debian.

Building postgresql-8.2-plproxy should be a debuild away, it should not
mean repackaging it.

And yes, I want to be able to minor-upgrade postgresql-8.2 (I'm already
without debian support here, and not by lack of volunteers) and its
extensions. Upstream is maintaining postgresql-8.2 until december
2011. And maybe some more, 7.4 is more than 6 years old now and still
maintained, for example.

>> Providing the extensions for 8.3 for stable when this version is no more
>> the official one should not require volunteers to edit or remake the
>> packaging.
>
>  If the extension for 8.3 for stable is in stable, what is the issue? If
> it isn't, backports.org is there to host such an addition, given that
> the extension is testing.
>
>  On the other hand, offering it through backports for 8.3 will make it
> more complicated to also offer it for 8.4 through backports - the
> package should be able to build both flavors (or the more practical one
> should be chosen).

I have 3 extensions packaged in such a way that they support both 8.3
and 8.4, see below. I'm being asked to remove their support for
providing both 8.3 and 8.4 packages, because they have to hit squeeze
without modifications and only produce 8.3 packages.

  http://packages.debian.org/source/sid/prefix
  http://packages.debian.org/source/sid/preprepare
  http://packages.debian.org/source/sid/hstore-new

If I do that, then I will have to edit my packages again to support 8.4
in sid, then later on 8.5, and I will have 1 packaging branch per debian
release. I want to avoid that.

Please also note that technically the code packaged here is compatible
with no modification with 8.1 and 8.2 too. The package which is included
in debian does not directly support those, and I know I have debian
users still in 8.1 and using prefix, e.g.

So ideally the extensions packaging should not have to be edited at all
and produce binaries for all supported PostgreSQL version. Supported by
the debian release which is building the package and by the extension
itself, of course.

>> PS: I surely do not intend to fix my packages by desuporting 8.3, even
>> if that means they don't get into squeeze when it's labelled
>> stable. Having them hosted outside of debian will be less work and
>> maintenance.
>
>  That's an unfortunate step you want to take. I hope the extension you
> maintain isn't an important one, otherwise I really would wish you
> rethink your standing.

Sorry. Maintaining my packages into debian is very far from zero effort,
but I'm happy to do it. Now if you add the burden to edit the packages,
meaning doing again all the QA stuff associated to it, then I prefer to
maintain my packages outside of debian: the cost outweight the benefit.

> P.S.: I think it would be really needed for companies that have interest
>    in having better postgres support within Debian to combined-hire a
>    person to specifically work on that task. The benefit would be
>    enormous, IMNSHO, and reduce the same kind of discussions on every
>    new postgres version or Debian release.

How will you get a company to be interrested into providing any kind of
effort into PostgreSQL debian packaging when debian still does not
understand how PostgreSQL is managed on production servers, and is not
interrested in hearing about it?

I think the solution would be either to have someone able to accept to
maintain PostgreSQL code in debian after upstream said there's no point
doing so, or for the debian project to accept that a software released
in a stable release could reach its EOL before the stable debian release
does.

Then we would have both PostgreSQL 8.3 and 8.4 in our next stable debian
release and everyone would be happy, users first. I just want to add
that PostgreSQL 8.3 will be maintained by upstream until February 2013,
and that the lifespan of squeeze, AFAIK, should expand from 2010 to
2012.

The more we talk about this, the less I see the point.

Regards,
-- 
dim