[Pkg-postgresql-public] postgresql 8.2 packaging

Dimitri Fontaine dfontaine at hi-media.com
Sun Mar 1 16:51:20 UTC 2009


Hi,

As a debian and PostgreSQL user, and a debian packager (albeit not a  
debian developer, I still maintain some packages in debian, some of  
them being postgresql related).
   http://qa.debian.org/developer.php?login=dim%40tapoueh.org

Le 1 mars 09 à 16:29, Paul E Condon a écrit :
> I think you are on the losing side of an argument, and deserve to
> lose, because your argument is mistaken. Debian packages PostgreSQL
> for the convenience of members of the Debian community, not as a
> service to the (larger?) PostgreSQL community.

I think you're so far away from reality here.
The service PostgreSQL offers to its user as far as older versions  
support is concerned is maintaining 5 back branches at any time. If  
you're using any major version of those, you still get bugfixes and  
security fixes from mainstream: 7.4 8.0 8.1 8.2 8.3.

Latest minor upgrades were released 2009-02-06 and are 8.3.6, 8.2.12,  
8.1.16, 8.0.20 and 7.4.24. You should also read the PostgreSQL  
versioning policy here:
   http://www.postgresql.org/support/versioning

Let's quote its first line:
   We always recommend that all users run the latest available
   minor release for whatever major version is in use.

Ok, that was for a common background on which to base our  
conversation. Now, how come debian system is flexible enough to be  
able to include more than one major version in debian trees, but not  
to allow its user to run the upstream recommended version?

We're still missing those three facts I think, to be able to answer:
  a. upgrading from 8.x to 8.y means a consequent to huge application  
development effort
  b. upgrading from 8.x.y to 8.x.z is done by restarting the service  
with the new binaries
  c. Martin wants to avoid having to support a major version longer  
than upstream

So it boils down to debian stable release schedule against PostgreSQL  
one, and I do think that debian still proposing 7.4.x without  
providing upgrades as soon as upstream marks this version EOL'd is a  
reasonable position.

The current position isn't one I can *not* understand, and it means I  
(and others, as Markus is showing) have problems to run debian stable  
with a currently maintained and stable PostgreSQL release (I do need  
to be running 8.1 and 8.2 in some places).

I've upgraded some applications from 7.2 straight to 8.2 and will  
probably skip 8.3 and even 8.4 completely for some of my applications,  
which is a perfectly fine and valid upgrading policy as far as  
upstream is concerned.

What I'm missing is not having production servers running both 8.2 and  
8.3 (which I seldom do (but still do)), it's having production servers  
running debian stable AND providing minor upgrades of the currently  
upstream maintained version I happen to *need*. Which means debian  
stable and PostgreSQL 8.1, 8.2 and 8.3, depending on applications.

> To me, the current policy works.

Do you happen to use PostgreSQL for production needs on a debian  
stable environment?
-- 
dim






More information about the Pkg-postgresql-public mailing list