Postgres major version support policy on Debian

Hi Markus,

Markus Wanner [2008-10-02 12:49 +0200]:

first of all: thanks for packaging Postgres for Debian. I'm willing to
help with that.

Nice!

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.

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.

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.

Disliking backports for that reason is perfectly ok, IMHO. After all,
backports cannot make any support promises, thus not using them is
actually a *good* thing on critical infrastructure. :-)

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.

I'm personally ok with that argument, but I'm not the backports.org
maintainer. If they have a general policy that they don't *ever*
upload something manual to backports.org, I suppose changing that
policy just for PostgreSQL is hard to do.

Of course there is always the possibility of offering a private
archive. For example, I maintained 8.1 backports for Sarge on
people.debian.org for quite a while, until backports.org got them.

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

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.

I still maintain 8.2 for Ubuntu 7.04 and 7.10, which I will have to do
for the next 7 months still. But after that I can get that off my
plate, and just maintain 8.1 and 8.3.

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

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

So, if the backports.org maintainers are ok with manual 8.2 uploads,
and you are willing to maintain them, that works for me. In that case
I'm happy to check your packages, and to discuss QA'ing procedures for
uploads.

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.

Thanks for starting the discussion!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi Martin,

Martin Pitt wrote:

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.

Okay.

I'm personally ok with that argument, but I'm not the backports.org
maintainer. If they have a general policy that they don't *ever*
upload something manual to backports.org, I suppose changing that
policy just for PostgreSQL is hard to do.

Of course there is always the possibility of offering a private
archive. For example, I maintained 8.1 backports for Sarge on
people.debian.org for quite a while, until backports.org got them.

Yeah, looks like that's what I will have to do, then.

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.

Good to hear. I'll see what I can do. Or you can let me know how to help
out. (The learning curve for becoming a Debian Maintainer or Uploader is
rather steep, IMO).

I still maintain 8.2 for Ubuntu 7.04 and 7.10, which I will have to do
for the next 7 months still. But after that I can get that off my
plate, and just maintain 8.1 and 8.3.

Aha, I'm going to compare those against my 8.2 backports, as there's
already a complaint about missing files in the -dev package.

That would basically lift backports.org to be an officially supported
Debian archive, which it isn't, and shouldn't be.

Well, there are exceptions to their rule. I think Postgres would make
another good exception. (CCing to backports because of this statement...)

So, if the backports.org maintainers are ok with manual 8.2 uploads,
and you are willing to maintain them, that works for me. In that case
I'm happy to check your packages, and to discuss QA'ing procedures for
uploads.

Cool.

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.

They already have.

Regards

Markus Wanner

Hi!

* Martin Pitt <mpitt@debian.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

Hi,

Gerfried Fuchs wrote:

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.

Don't be sorry. I still appreciate having an up to date Postgres version
available on etch. (And I still think it's the right thing to support
multiple major versions.)

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?

Well, it's a general Postgres problem, not a Debian one. Upgrading
between major versions requires a full dump/restore cycle, for which the
downtime is proportional to the database size. For small or medium
databases that's not an issue, but above some Gigabytes, that begins to
hurt pretty badly.

Another problem also mentioned in the cited threads is that of custom
built or contrib modules which are often problematic (i.e. costly to
adjust) to upgrade as well.

Once Postgres supports in-place upgrades between major versions, this
issue is solved.

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

Uhm.. I'm mistyping sometimes, but not this time. [2] references:
http://archives.postgresql.org/message-id/48E48822.5060009@usit.uio.no

Which is certainly not from me.

And you failed to outline the
"enough of a reason for an exception" argument you like to brag around
with.

Well, at least several hours of downtime is enough of a reason for many
people to not upgrade between major Postgres versions. It certainly is
for us. And judging from the Postgres mailing lists, there are still
quite some people on 7.4 just for these reasons.

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.

Okay, that's fine.

In that case, 8.2 should never have been backported. And very likely 8.4
shouldn't be backported either. Which is a pity IMO, and justifies an
exception of such a rule.

Note that I'm not just complaining, but offering to help and do better
myself: I continue to maintain "backports" of 8.2.

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.

That's why I'm cross-posting this, yes.

Having a rule like that would though mean that an ancient version would
never be able to get removed anywhere at all,

No. The Debian project could perfectly well drop it as soon as upstream
drops support for it (which has often been around five years after the
initial release, so far).

Note that these are bugfixes only and backporting those is certainly as
much work as supporting a new major version. Often enough, this should
just mean upgrading the sources, without having to adjust anything
debian specific.

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.

Nobody is telling anyone else what to do here.

I've created Debian packages and would like to find a good way to offer
them to the broad public via the Debian infrastructure. I'm trying to
find out the best way to do that. End of the story.

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.

Uh.. that's what my first proposal was about: maintaining all major
versions in testing.

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

Well, it's pretty sure by now that Postgres 8.3 will be shipped with lenny.

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.

Again, please don't be sorry. I appreciated having 8.2 (and now 8.3)
available from the backports. So do lots of other users, AFAICT.

However, silently removing a major version is not an option, IMO.

Regards

Markus Wanner

Markus Wanner wrote:

Gerfried Fuchs wrote:

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.

Don't be sorry. I still appreciate having an up to date Postgres version
available on etch. (And I still think it's the right thing to support
multiple major versions.)

If there are no backported packages for any given Postgres major
version, what will happen is that a lot of people will be forced to
build them from source, which is a lot worse. (There is a reason why
PGDG provides RPM for all major versions, for a lot of Redhat
distributions -- people do want them).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Gerfried Fuchs [2008-10-06 17:04 +0200]:

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,

It is, and I think that -8.3 in backports makes perfect sense.
It is what Lenny will ship with, and thus will be maintained for the
next couple of years.

(If it helps, I'll do -8.3 package maintenance for the next 5 years
for Ubuntu 8.04 LTS)

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi Markus,

Markus Wanner [2008-10-06 17:34 +0200]:

Note that these are bugfixes only and backporting those is certainly as
much work as supporting a new major version. Often enough, this should
just mean upgrading the sources, without having to adjust anything
debian specific.

Right. The Debian packages are done in a way that almost all the
packaging/integration/upgrade/configuration logic is in
postgresql-common, and the postgresql-X.Y packages just ship the "bare
bits".

When there is a new upstream release, I upgrade the source package to
the new tarball, adapt the patches (which is most of the time a
no-op), build it (which will run the upstream test suite), install
them, run the postgresql-common integration test suite (which
exercises pretty much everything you can do with the package), and
upload if all goes well. That process takes roughly 15 minutes of work
time if you are experienced with the package (plus half an hour to
wait for p-common's test suite).

So it's not a lot of work, but it must be done regularly and in time.

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Mon, Oct 6, 2008 at 9:34 AM, Markus Wanner <markus@bluegap.ch> wrote:

Hi,

Gerfried Fuchs wrote:

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?

Well, it's a general Postgres problem, not a Debian one. Upgrading
between major versions requires a full dump/restore cycle, for which the
downtime is proportional to the database size. For small or medium
databases that's not an issue, but above some Gigabytes, that begins to
hurt pretty badly.

In that case I prefer to have both db versions available and use slony
to upgrade in place. We recently upgraded from 8.1 to 8.3 and work
the downtime was measured in seconds (the time it took slony to switch
the two servers). We ran Ubuntu, but the new servers are running
Centos 5.2 mainly because that OS is more stable on our large db
server platforms while Ubuntu 8.04 was very unstable (kernel problems)
and Ubuntu 7.10 wouldn't finish an install.

Once Postgres supports in-place upgrades between major versions, this
issue is solved.

It has in the past but apparently the work required in coding and
testing was too much and it the upgrade in place stuff was abandoned.
Someone please correct me if I'm wrong and someone is working on it
again.

And you failed to outline the
"enough of a reason for an exception" argument you like to brag around
with.

Well, at least several hours of downtime is enough of a reason for many
people to not upgrade between major Postgres versions. It certainly is
for us. And judging from the Postgres mailing lists, there are still
quite some people on 7.4 just for these reasons.

Again, Slony works wonders here, if your machines can handle the
initial load produced by the slony subscription process.

I've created Debian packages and would like to find a good way to offer
them to the broad public via the Debian infrastructure. I'm trying to
find out the best way to do that. End of the story.

I would think that setting up a repo would be the best way to do it.

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.

Uh.. that's what my first proposal was about: maintaining all major
versions in testing.

It would seem that a diverse environment for testing would be the best
policy to pursue.

Hi again :)

* Markus Wanner <markus@bluegap.ch> [2008-10-06 17:34:13 CEST]:

Gerfried Fuchs wrote:

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?

Well, it's a general Postgres problem, not a Debian one. Upgrading
between major versions requires a full dump/restore cycle, for which the
downtime is proportional to the database size. For small or medium
databases that's not an issue, but above some Gigabytes, that begins to
hurt pretty badly.

Then again, that was already required when switching from 8.1 to 8.2.
And it was never a secret that backports.org is a moving target, just as
testing is, where the backported versions on backports.org come from.

Another problem also mentioned in the cited threads is that of custom
built or contrib modules which are often problematic (i.e. costly to
adjust) to upgrade as well.

Likewise, 8.2 was never in stable so people already must have done that
thing at least once.

Once Postgres supports in-place upgrades between major versions, this
issue is solved.

Good to hear. :)

Erm, the referenced mail [2] refers to your own mail, so using that as
a reasoning argument is a bit fishy ...

Uhm.. I'm mistyping sometimes, but not this time. [2] references:
http://archives.postgresql.org/message-id/48E48822.5060009@usit.uio.no

Which is certainly not from me.

Yes. But the only thing given therein is a reference to the thread
started by you. That user clearly wants a clean stable system and seems
to be well aware of what backports.org might gain him, or might not. And
I don't think that your approach with yet another repository will make
him happy neither.

And you failed to outline the
"enough of a reason for an exception" argument you like to brag around
with.

Well, at least several hours of downtime is enough of a reason for many
people to not upgrade between major Postgres versions. It certainly is
for us. And judging from the Postgres mailing lists, there are still
quite some people on 7.4 just for these reasons.

And that's absolutely fine and that's what the stable releases in
Debian are for. Backports.org is a moving target that is there to
support backports from testing (which is obviously a moving target,
too), and people doing upgraded from stable to versions from
backports.org should hopefully be aware of that. New version usually
mean new interfaces for working with them, and I don't see why this
should be considered differently for postgres ...

People who are worried about downtimes for upgrades should never follow
a moving target, might it be testing, backports.org or anything else.

Who is this "us" by the way, so just that "we" know who we are speaking
about?

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.

Okay, that's fine.

In that case, 8.2 should never have been backported.

Why do you claim so? It was a helpful ressource for quite some people.

And very likely 8.4 shouldn't be backported either. Which is a pity
IMO, and justifies an exception of such a rule.

Why do you think so? What makes postgres so outrageous special in this
area than any other package?

Note that I'm not just complaining, but offering to help and do better
myself: I continue to maintain "backports" of 8.2.

But with that you are just adding to the diversion which you so
strongly try to fight ...

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.

That's why I'm cross-posting this, yes.

But you haven't cross-posted it to the debian-project list (which
doesn't rule backports.org currently, but there's work underway here). I
guess having your original mail not sent to backports-users was a
mistake, you did bounce it there later.

Having a rule like that would though mean that an ancient version would
never be able to get removed anywhere at all,

No. The Debian project could perfectly well drop it as soon as upstream
drops support for it (which has often been around five years after the
initial release, so far).

Erm, that's extremely kind of you. Do you really want to go the path of
claiming that it's non-debian's decisions when Debian drops support for
a package? I consider that highly arrogant and unpractical.

Note that these are bugfixes only and backporting those is certainly as
much work as supporting a new major version. Often enough, this should
just mean upgrading the sources, without having to adjust anything
debian specific.

I am not even talking about the effort of doing the backport. I would
happily support maintaining the pg 8.2 backports for longer, it just
doesn't make that much sense to me, especially not doing the work on a
voluntary basis when I'm not convinced myself by the big usefulness for
it. Please notice again with all the ruling and opression you want to
put onto the Debian project that you are not in the palce to do so.

Nobody is telling anyone else what to do here.

No? You clearly are requesting that this and that to be done, but noone
is telling anyone else what to do here? Either I read completely
different mails from what you write, or there's something going wrong
here ...

I've created Debian packages and would like to find a good way to offer
them to the broad public via the Debian infrastructure. I'm trying to
find out the best way to do that. End of the story.

Unfortunately, you don't seem to understand how the Debian
infrastructure works (which several people tried to explain to you),
otherwise you wouldn't claim that.

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.

Uh.. that's what my first proposal was about: maintaining all major
versions in testing.

That would also mean maintaining them in unstable, too, just to get
things straight. And there just isn't enough power to do so properly,
unfortunately.

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

Well, it's pretty sure by now that Postgres 8.3 will be shipped with lenny.

That wasn't the question. You can't be completely sure (long delays
have happened in the past), and at the time you can be sure quite some
people already starting to test upgrades so the reason for preparing the
backport might already be pretty little.

Again, please don't be sorry. I appreciated having 8.2 (and now 8.3)
available from the backports. So do lots of other users, AFAICT.

That's what I actually thought before you started with this threads,
trying to put your opinion and how things should work onto others.

However, silently removing a major version is not an option, IMO.

But it was *NOT* done silently. I'm sorry if you haven't followed the
list before, but it was announced on the list (backports-users, that
is - and that's the list people using backports.org are meant to read).

So long,
Rhonda

On Mon, 6 Oct 2008, Scott Marlowe wrote:

On Mon, Oct 6, 2008 at 9:34 AM, Markus Wanner <markus@bluegap.ch> wrote:

Once Postgres supports in-place upgrades between major versions, this
issue is solved.

It has in the past but apparently the work required in coding and
testing was too much and it the upgrade in place stuff was abandoned.
Someone please correct me if I'm wrong and someone is working on it
again.

There's a prototype being actively worked on and if we're lucky it will
debut in 8.4 this March. See
http://archives.postgresql.org/message-id/48BB10A2.60503@sun.com for the
last code submission there and
http://wiki.postgresql.org/wiki/In-place_upgrade for an outline of the
project.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Hi,

Gerfried Fuchs wrote:

Then again, that was already required when switching from 8.1 to 8.2.
And it was never a secret that backports.org is a moving target, just as
testing is, where the backported versions on backports.org come from.

While that's correct, nobody was forced to do that switch, because 8.1
is still maintained in etch, while 8.2 is not maintained anywhere
anymore, forcing people to switch.

Yes. But the only thing given therein is a reference to the thread
started by you. That user clearly wants a clean stable system and seems
to be well aware of what backports.org might gain him, or might not. And
I don't think that your approach with yet another repository will make
him happy neither.

True. And from what I can tell, he got that impression from the thread I
started, yes. It outlines a maintenance problem of Postgres from backports.

That's why I'd like to merge those packets into backports, at least.
Better yet, back into the main Debian project.

And that's absolutely fine and that's what the stable releases in
Debian are for. Backports.org is a moving target that is there to
support backports from testing (which is obviously a moving target,
too), and people doing upgraded from stable to versions from
backports.org should hopefully be aware of that. New version usually
mean new interfaces for working with them, and I don't see why this
should be considered differently for postgres ...

I disagree here. If backported packages don't even try to be as stable
as the stable version they are backported to, there's no point in
backporting.

Testing is a movable target, yes. But backports shouldn't be, IMO.
Otherwise, why should I use backports at all?

People who are worried about downtimes for upgrades should never follow
a moving target, might it be testing, backports.org or anything else.

Sure?

The backports.org website describes the project as follows:

"You are running Debian stable, because you prefer the stable Debian
tree. It runs great, there is just one problem: the software is a little
bit outdated compared to other distributions. That is where backports
come in."

That's exactly how I understand what "backports" are. Striving to reach
high stability for selected packages from the "future" (seen from the
particular stable release).

The front page continues to explain:

"Backports are recompiled packages from testing (mostly) and unstable
(in a few cases only, e.g. security updates)"

So there must already be other exceptions for good reasons.

Who is this "us" by the way, so just that "we" know who we are speaking
about?

In this case that should have read "me and the people from the company
I'm working for". We run several etchy systems with backported Postgres
8.2 (because we need some of the 8.2 features).

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.

Okay, that's fine.

In that case, 8.2 should never have been backported.

Why do you claim so? It was a helpful ressource for quite some people.

I absolutely agree. Heck we are productively using it. So do lots of
other people, because they want newer software to run on a stable
system. And they want the newer software to be as stable as their old
system whenever possible. That's why I'm saying 8.2 shouldn't just be
dropped.

Why do you think so? What makes postgres so outrageous special in this
area than any other package?

I think I've explained that enough, now.

Note that I'm not just complaining, but offering to help and do better
myself: I continue to maintain "backports" of 8.2.

But with that you are just adding to the diversion which you so
strongly try to fight ...

What diversion do you mean here?

I'm trying to get Postgres 8.2 back into backports (or testing and thus
backports as well) to reduce diversion of repositories and Debian
packages for Postgres.

Responses to this effort and downloads from my repository indicate, that
there are enough other people wanting a stable and maintained Postgres
8.2 from Debian.

But you haven't cross-posted it to the debian-project list (which
doesn't rule backports.org currently, but there's work underway here). I
guess having your original mail not sent to backports-users was a
mistake, you did bounce it there later.

I didn't know that, sorry. I'm already cross-posting to three mailing
lists. How complicated can "wanting to help" be? Why does a mailing list
as general as a "debian-project" list need to deal with such an issue?

No. The Debian project could perfectly well drop it as soon as upstream
drops support for it (which has often been around five years after the
initial release, so far).

Erm, that's extremely kind of you. Do you really want to go the path of
claiming that it's non-debian's decisions when Debian drops support for
a package? I consider that highly arrogant and unpractical.

I'm offering to help supporting Debian packages across all Postgres
major versions since 8.1. And as long as Postgres upstream itself
provides updates and bugfixes. I fail to see the arrogance in that. And
at least for me, it's more practical than being forced to upgrade. It's
just less work.

I am not even talking about the effort of doing the backport. I would
happily support maintaining the pg 8.2 backports for longer, it just
doesn't make that much sense to me, especially not doing the work on a
voluntary basis when I'm not convinced myself by the big usefulness for
it.

That's fine. You don't need to do it. I already did.

Unfortunately, you don't seem to understand how the Debian
infrastructure works

That's obviously true to some extent. I'm trying to figure out and
understand.

That would also mean maintaining them in unstable, too, just to get
things straight. And there just isn't enough power to do so properly,
unfortunately.

Refusing help isn't exactly going to encourage others.

Well, it's pretty sure by now that Postgres 8.3 will be shipped with lenny.

That wasn't the question. You can't be completely sure (long delays
have happened in the past), and at the time you can be sure quite some
people already starting to test upgrades so the reason for preparing the
backport might already be pretty little.

Agreed.

Keeping to maintain all major Postgres versions in testing (and
unstable) would solve that issue as well.

But it was *NOT* done silently. I'm sorry if you haven't followed the
list before, but it was announced on the list (backports-users, that
is - and that's the list people using backports.org are meant to read).

True. Sorry.

Regards

Markus Wanner

Hi,

Alvaro Herrera wrote:

If there are no backported packages for any given Postgres major
version, what will happen is that a lot of people will be forced to
build them from source, which is a lot worse. (There is a reason why
PGDG provides RPM for all major versions, for a lot of Redhat
distributions -- people do want them).

Uh.. in case that didn't get clear: I've already done the backports of
Postgres 8.2.9 and 8.2.10 for debian etch. You can get these packages
from the temporary repository here: http://www.bluegap.ch/debian/

Regards

Markus Wanner

Hi,

Martin Pitt wrote:

So it's not a lot of work, but it must be done regularly and in time.

That's good news. And about my experience when backporting 8.2.9 and
8.2.10 for etch as well.

Do I understand correctly, that https://code.launchpad.net/postgresql
currently holds the debian packaging files in a bazaar repository?

Regards

Markus Wanner

Hi Markus,

Markus Wanner [2008-10-07 11:08 +0200]:

Do I understand correctly, that https://code.launchpad.net/postgresql
currently holds the debian packaging files in a bazaar repository?

It has branches for p-common and 8.3.

http://arch.debian.org/arch/pkg-postgresql/mpitt/ has the branches for
etch (7.4 and 8.1). I set the public branch for 8.2 [1]https://code.launchpad.net/~pitti/postgresql/debian-8.2 to "abandoned",
since I don't maintain it any more. However, I'm fine with reviving it
if you want to take it over. (If you don't want to maintain it on LP,
put it somewhere else, and I convert it to be a mirror of your branch)

Thanks,

Martin

[1]: https://code.launchpad.net/~pitti/postgresql/debian-8.2

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Markus Wanner wrote:

Hi,

Alvaro Herrera wrote:

If there are no backported packages for any given Postgres major
version, what will happen is that a lot of people will be forced to
build them from source, which is a lot worse. (There is a reason why
PGDG provides RPM for all major versions, for a lot of Redhat
distributions -- people do want them).

Uh.. in case that didn't get clear: I've already done the backports of
Postgres 8.2.9 and 8.2.10 for debian etch. You can get these packages
from the temporary repository here: http://www.bluegap.ch/debian/

Not having followed the whole discussion here.. But if location is the
only issue, we could perhaps provide a repository on the postgresql.org
servers for this, in case Debian does not want it on their official ones?

//Magnus

Hi,

Magnus Hagander wrote:

Not having followed the whole discussion here.. But if location is the
only issue, we could perhaps provide a repository on the postgresql.org
servers for this, in case Debian does not want it on their official ones?

Thanks for the offer, but location is not really the issue here.

I'm in contact with Martin Pitt, who's the only maintainer of the
Postgres packages for Debian. Helping him with maintaining these
packages is a good thing per se, IMO. I'm trying to join forces and not
diversify.

Regards

Markus Wanner

Hi!

One (hopefully) last reply. :)

* Markus Wanner <markus@bluegap.ch> [2008-10-07 10:52:55 CEST]:

Gerfried Fuchs wrote:

Then again, that was already required when switching from 8.1 to 8.2.
And it was never a secret that backports.org is a moving target, just as
testing is, where the backported versions on backports.org come from.

While that's correct, nobody was forced to do that switch, because 8.1
is still maintained in etch, while 8.2 is not maintained anywhere
anymore, forcing people to switch.

But those people already chose a switching path so the impact isn't
that diverse. And it's still nothing postgres specific here, people
chosing backports are chosing a moving target.

That's why I'd like to merge those packets into backports, at least.
Better yet, back into the main Debian project.

It would have to flow from the main pool to backports. I am no
authority here, even though I understand that it might sound a bit like
it, but I don't see the chances for the exception in this case.

I disagree here. If backported packages don't even try to be as stable
as the stable version they are backported to, there's no point in
backporting.

There definitely is. Backported packages offer newer features onto an
*otherwise* stable and (security-)supported system. While I strive to
get the latter part fixed and more timely addressed and included into
the security-tracker.debian.net, it still isn't there. The overall
quality is pretty high because only Debian Developers are usually
allowed to upload into backports, but there are different rules that
apply here still.

Testing is a movable target, yes. But backports shouldn't be, IMO.
Otherwise, why should I use backports at all?

To have newer features within a small subgroup of packages. Take e.g.
the pidgin package. It was updated several times with newer features but
also changed interfaces. A backported package is per definition a moving
target and not a static content, otherwise you won't ever be able to
update it at all.

People who are worried about downtimes for upgrades should never follow
a moving target, might it be testing, backports.org or anything else.

Sure?

Yes, sure.

"You are running Debian stable, because you prefer the stable Debian
tree. It runs great, there is just one problem: the software is a little
bit outdated compared to other distributions. That is where backports
come in."

That's exactly how I understand what "backports" are. Striving to reach
high stability for selected packages from the "future" (seen from the
particular stable release).

No. Striving to not affect the high stability of the _base_ system is
why it's done. While striving to have high stability for the packages
within backports, it's core reason of existence is to *not* influence
the base system unto which it's applied to.

Following your reasoning one could argue that you are calling pg 8.3
not having a high stability.

The front page continues to explain:

"Backports are recompiled packages from testing (mostly) and unstable
(in a few cases only, e.g. security updates)"

So there must already be other exceptions for good reasons.

Yes. But pg 8.2 is neither in testing nor in unstable.

Who is this "us" by the way, so just that "we" know who we are speaking
about?

In this case that should have read "me and the people from the company
I'm working for". We run several etchy systems with backported Postgres
8.2 (because we need some of the 8.2 features).

Alright, thanks. To some degree I got the impression by the writing
style you chose that you were part of and speaking for the postgres team ...

In that case, 8.2 should never have been backported.

Why do you claim so? It was a helpful ressource for quite some people.

I absolutely agree. Heck we are productively using it. So do lots of
other people, because they want newer software to run on a stable
system. And they want the newer software to be as stable as their old
system whenever possible. That's why I'm saying 8.2 shouldn't just be
dropped.

Sorry to say so then but your wording was badly chosen in some parts. I
don't deny that propably mine too, and given that we both seem to be
German natives discussing this in English even sounds like fishing for
even more problems here.

Responses to this effort and downloads from my repository indicate, that
there are enough other people wanting a stable and maintained Postgres
8.2 from Debian.

I never really denied that. It's just that it wouldn't follow the
current workflow that did hinder me to maintain it in the way it was
before...

But you haven't cross-posted it to the debian-project list (which
doesn't rule backports.org currently, but there's work underway here). I
guess having your original mail not sent to backports-users was a
mistake, you did bounce it there later.

I didn't know that, sorry. I'm already cross-posting to three mailing
lists. How complicated can "wanting to help" be? Why does a mailing list
as general as a "debian-project" list need to deal with such an issue?

Because the way you worded your mails made it sound like you wanted to
have some rules enforced that are out of the scope of the lists you post
to.

No. The Debian project could perfectly well drop it as soon as upstream
drops support for it (which has often been around five years after the
initial release, so far).

Erm, that's extremely kind of you. Do you really want to go the path of
claiming that it's non-debian's decisions when Debian drops support for
a package? I consider that highly arrogant and unpractical.

I'm offering to help supporting Debian packages across all Postgres
major versions since 8.1. And as long as Postgres upstream itself
provides updates and bugfixes. I fail to see the arrogance in that. And
at least for me, it's more practical than being forced to upgrade. It's
just less work.

I won't explain further here why I called that attitude arrogant, we
can do that in private and propably in German to reduce the language
barrier. And I'm glad to hear that you want to join the packaging team,
thanks.

Unfortunately, you don't seem to understand how the Debian
infrastructure works

That's obviously true to some extent. I'm trying to figure out and
understand.

If you like and don't hold this discussion against me feel free to
pester me with anything you like to. :)

That would also mean maintaining them in unstable, too, just to get
things straight. And there just isn't enough power to do so properly,
unfortunately.

Refusing help isn't exactly going to encourage others.

I didn't refuse any help, there actually currently isn't (or, rather
wasn't before of your offer) enough manpower to go that path. This
wasn't a refusing of your offer but rather pointing out the current
status quo, sorry if you got that wrong.

Keeping to maintain all major Postgres versions in testing (and
unstable) would solve that issue as well.

If we are able to work it out I'm all for doing so.

But it was *NOT* done silently. I'm sorry if you haven't followed the
list before, but it was announced on the list (backports-users, that
is - and that's the list people using backports.org are meant to read).

True. Sorry.

No worries - and like hinted above, I'm also sorry for having sounded
pretty strict, but I just wanted to point the things out properly
instead of doing it like some others with a "no, won't work" reply. ;)

So long, and looking forward to hearing from you soon.
Rhonda

Hi,

I enjoy discussing and I think we are getting closer to an understanding
with every mail.

Gerfried Fuchs wrote:

It would have to flow from the main pool to backports. I am no
authority here, even though I understand that it might sound a bit like
it, but I don't see the chances for the exception in this case.

Okay. Looks like I'm rather trying to join the "official" packaging team
and bring Postgres 8.2 back alive on testing. We'll soon see how that
turns out.

To have newer features within a small subgroup of packages. Take e.g.
the pidgin package. It was updated several times with newer features but
also changed interfaces. A backported package is per definition a moving
target and not a static content, otherwise you won't ever be able to
update it at all.

I think the main difference in understanding here is the updatability of
Postgres. I'm clearly thinking of Postgres 8.2 as a very different
package than Postgres 8.3.

We have more than one server where we are running *both* in parallel and
want to keep it that way. (Where "we" is Programmfabrik GmbH again). (In
fact even one where an additional 8.1 is running).

I think it's quite similar to python2.{3,4,5}.: sure one "can"
theoretically upgrade (with enough time and resources). But more often
enough one simply doesn't want to.

No. Striving to not affect the high stability of the _base_ system is
why it's done. While striving to have high stability for the packages
within backports, it's core reason of existence is to *not* influence
the base system unto which it's applied to.

I fail to see how that can be a reason for backports to exist. If your
main motivation is not to influence the base system, you certainly don't
need any backports.

Backporting always is a compromise between stability (of the old
software) and new features, IMO.

The front page continues to explain:

"Backports are recompiled packages from testing (mostly) and unstable
(in a few cases only, e.g. security updates)"

So there must already be other exceptions for good reasons.

Yes. But pg 8.2 is neither in testing nor in unstable.

Agreed.

Sorry to say so then but your wording was badly chosen in some parts. I
don't deny that propably mine too, and given that we both seem to be
German natives discussing this in English even sounds like fishing for
even more problems here.

Yeah...

I never really denied that. It's just that it wouldn't follow the
current workflow that did hinder me to maintain it in the way it was
before...

Understood.

I've been coming from another direction, thinking that adding Postgres
8.2 to only backports would be easier than adding it to Debian proper.
Maybe that's plain wrong. And Martin Pitt seems to be glad to get some
help...

Because the way you worded your mails made it sound like you wanted to
have some rules enforced that are out of the scope of the lists you post
to.

Sorry if it sounded that way. I just wanted to know in what direction I
should go with Postgres 8.2 packages.

And yes, I must admit that I've been a bit disappointed by "suddenly"
(didn't read the backport-users...) missing Postgres 8.2 upgrades.

I won't explain further here why I called that attitude arrogant, we
can do that in private and propably in German to reduce the language
barrier. And I'm glad to hear that you want to join the packaging team,
thanks.

Cool.

If you like and don't hold this discussion against me feel free to
pester me with anything you like to. :)

Thanks for the offer. I'm trying keep the discussion on the topic and to
avoid personal offense.

Keeping to maintain all major Postgres versions in testing (and
unstable) would solve that issue as well.

If we are able to work it out I'm all for doing so.

I'll try.

No worries - and like hinted above, I'm also sorry for having sounded
pretty strict, but I just wanted to point the things out properly
instead of doing it like some others with a "no, won't work" reply. ;)

Hehe.. it certainly helped me better than than, yeah. Thanks for
productive criticism.

Regards

Markus Wanner

Magnus Hagander wrote:

Not having followed the whole discussion here.. But if location is the
only issue, we could perhaps provide a repository on the postgresql.org
servers for this, in case Debian does not want it on their official ones?

It would be a fallacy to assume that space is the only problem. Debian
probably has more servers than PostgreSQL.

The problem is that quality package maintenance needs other
infrastructure support. There is a whole of host of things for package
tracking, package search, bug tracking, transition tracking, maintainer
tracking built around the packages hosted for example by Debian and
Ubuntu, and other groups as well. Sure you can just dump additional
packages on some server, but then it doesn't really fit into the rest of
the scheme. And the problem is that this scheme defines certain buckets
of packages such as stable, testing, unstable, volatile, backports, etc.
that have relationships between them. And unfortunately the maintenance
model that Markus wants for postgresql-8.2 does not fit into any
existing bucket yet. So the proper fix would be defining a new bucket,
which can probably be a very difficult task. In the meantime, the other
path would be lobbying for an exception for some of the other buckets,
which is unlikely to be approved because a lot of the management is done
automatically and therefore does not allow human-defined exceptions. So
the last choice then is doing maintenance on your own.