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

[Gerfried Fuchs]

	Hi again!

[dropping debian-release because that's not really of importance there]

* Dimitri Fontaine <dfontaine at hi-media.com> [2009-12-28 15:46:25 CET]:
> Ok that's easy. Really, that's only too easy: I have several PostgreSQL
> 8.2 in production in debian etch and lenny today.

 Unfortunately, 8.2 never was in any stable release. Yes, I did upload
it to backports (me, myself) and thought at that time that it would be a
target for lenny. I did do that in good faith, unfortunately I got a
load of scathing feedback when I didn't see a proper path to continue to
support it there, under the rules of the service and under sane effort
to maintain it.

> 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.

 Then I think those users shouldn't complain too much - or rather, not
just complain but offer solutions for the various mentioned problems
with going that path. I haven't yet seen proper offers or suggestions in
that direction, though.

> 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.

 Using packages from testing on production machines isn't a good idea
anyway. Appart from that, see above, I'm sorry for the mess 8.2 in
backports meant - but this time I am well aware what 8.4 in
lenny-backports means and I explicitly stated that on my upload and the
requests that I received for it: It might get eventually discontinued
when 8.5 and squeeze releases are fit for it.

> 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.

 Sorry to hear that, but the way Debian does its releases never was a
secret, and actually in this respect postgres is only unique in _one_
tiny bit compared to any other package in Debian: The release team
allows patch updates to the releases to go into stable; otherwise we
would still have 8.3.6 (+ security patches) in stable.

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

 How about adding special support in debian/rules with respect to a
DEB_BUILD_OPTIONS variable? Shouldn't be *too* complicated, and a valid
and nice approach.

> 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.

 Though, 7.4 isn't very much advertised, it is missing in the righthand
corner of LATEST RELEASES on postgresql.org.

> 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.

 Erm, only 8.4 packages. :)

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

 Then you are already there, and for offering it through backports you
just have to enable the switch to build both again to offer 8.3 and 8.4
for stable through there.

> 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.

 How often do you update the "branches" for the debian releases? Usually
you only need the branches if you have to fix bug in a past release, not
for regular work, it's only the "unstable branch" you follow with your
work.

> 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.

 That's because it wasn't in oldstable where 8.1 was available. Then you
could have added it for etch-backports to offer it to them through the
official means.

> 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.

 Hmm, I guess some "magic" could be added to debian/rules, that should
be possible and a path to follow. Actually, I think Luk misunderstood
you with this point initially.

> Sorry. Maintaining my packages into debian is very far from zero effort,
> but I'm happy to do it.

 Maintaining any packages is very far from zero effort - and the Debian
policy, even if it might be seen as a burden, is the core thing that
keeps our distribution stable and solid what it is known for. With
respect to quality, there are no compromises one should make, IMNSHO.

> 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.

 The benefit would be for users to have it through the official channels
which they rely on and trust.

> > 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?

 Why do you claim that Debian doesn't understand that? Why don't you
rather think about that Debian already *has* a very specific exception
for postgresql in place? And why do you claim that Debian isn't
interested in hearing about it? Sorry, those claims are just FUD and not
helping in any sense, neither your mission nor postgresql nor anything.

> 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

 That would require being a postgresql developer, or having at least
similar deep insight into the source; otherwise they won't be able to
"maintain" it.

> 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.

 Of course it can, and it accepts it. Packages got removed from stable
in the past when there was not much way around that.

 The Debian project just doesn't like to release stuff in stable that is
*KNOWN* to potentially reach its EOL before the stable debian release
does. That's a *HUGE* difference.

> 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.

 Rather 2013, and then we stumble into exactly the issue that Martin
actually likes to avoid, and that I personally consider very much
understandable.

 Thanks,
Rhonda
P.S.: It might not be completely clear, but nevertheless: I express my
   own point of view, being a debian developer for a long time now. My
   impressions aren't neccessarily the ones of the project as a whole,
   not even the ones of a postgresql package team. I though still think
   that they are in most parts pretty similar though. Feel free to
   correct me in case I blabber nonsense.