Thread: Postgres major version support policy on Debian

Hi,

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

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.

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.

Upgrading via pg_upgradecluster is definitely not an option due to
custom build extensions and because of the downtime involved.

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.


Anyway, I'd like to reach an agreement on a decent policy about Postgres
major version support especially WRT the backports. I see these options:

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

 * Postgres major versions dumped from testing, but once added to any
backport should be maintained on backports even if it gets dumped from
testing.

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


Looking at it that way, I'm favoring the first option. However, I'd be
fine with the second as well. The third would be a pity, but still
better than status quo (because backports currently makes false promises
about maintenance of backported Postgtres major versions, IMO).

As already mentioned, I'm offering help in maintaining these packages.
I'm somewhat experienced in Debian packaging, but not familiar with
uploading or maintaining "official" packages (keen to learn, though).

Regards

Markus Wanner


[1]: announcement of my Postgres 8.2 backports:
http://lists.backports.org/lurker-bpo/message/20080923.161529.60f37f97.en.html

[2]: newish complaint on the postgres performance mailing list:
http://archives.postgresql.org/message-id/48E48822.5060009@usit.uio.no

[3]: backport policy argument, see also rest of the thread
http://archives.postgresql.org/message-id/48DA73E4.7060505@gmx.net

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,

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.

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] 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,

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

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

    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

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.

Hi,

Peter Eisentraut wrote:
> 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.

..or simply use another bucket. I'm trying to help Martin Pitt with
general purpose Postgres packaging. Maybe we can revive Postgres 8.2 for
Debian that way. Or do you see any immediate problem with that strategy?

Regards

Markus Wanner

Markus Wanner wrote:
> Hi,

> ..or simply use another bucket. I'm trying to help Martin Pitt with
> general purpose Postgres packaging. Maybe we can revive Postgres 8.2 for
> Debian that way. Or do you see any immediate problem with that strategy?

I don't, there are plenty of one off repositories in the world for
things Debian and Ubuntu can't bother to package. Although in Ubuntu we
can use Multi/Uni verse.

CMD would be happy to help with this.

Joshua D. Drake

Markus Wanner [2008-10-07 20:08 +0200]:
> 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.

That's in fact the option I have most trouble with. Reason is that
major upstream releases are roughly maintained for five years. All
packages in Lenny main will be supported for Lenny's lifetime, which
is in the order of 4 years (time to release plus, say, 3 years until
the next Debian release comes out, plus one year of "oldstable"
security/bug fix support).

However, postgresql-8.2 is already a little less than 2 years old,
which means that we will need to backport patches in Debian for over a
year. I think it will just barely work with supporting 8.1 in Etch and
8.3 in Lenny, but 8.2 will mean trouble. That's the primary reason
why I only want to support the latest version in a stable release. I
just can't commit to doing all that backporting work myself.

So a compromise I can live with is to put it back into unstable (or
even just experimental), but never let it propagate to testing. Then
backports.org can do mechanized backports of updates without being
tied to the long lifecycle of Lenny. Would that be an acceptable
compromise for all involved parties?

Thanks,

Martin

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

Hi,

Martin Pitt wrote:
> That's in fact the option I have most trouble with. Reason is that
> major upstream releases are roughly maintained for five years. All
> packages in Lenny main will be supported for Lenny's lifetime, which
> is in the order of 4 years (time to release plus, say, 3 years until
> the next Debian release comes out, plus one year of "oldstable"
> security/bug fix support).

Understood.

> However, postgresql-8.2 is already a little less than 2 years old,
> which means that we will need to backport patches in Debian for over a
> year. I think it will just barely work with supporting 8.1 in Etch and
> 8.3 in Lenny, but 8.2 will mean trouble. That's the primary reason
> why I only want to support the latest version in a stable release. I
> just can't commit to doing all that backporting work myself.

I didn't mean to put more work on your shoulders. Quite the opposite, in
fact.

> So a compromise I can live with is to put it back into unstable (or
> even just experimental), but never let it propagate to testing. Then
> backports.org can do mechanized backports of updates without being
> tied to the long lifecycle of Lenny. Would that be an acceptable
> compromise for all involved parties?

That works for me.

Can you act as a sponsor for uploading 8.2 packages to experimental or
unstable?

Regards

Markus Wanner

Markus Wanner [2008-10-09 22:53 +0200]:
> Can you act as a sponsor for uploading 8.2 packages to experimental or
> unstable?

Of course.

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

Alexander Wirt [2008-10-10  7:02 +0200]:
> > > So a compromise I can live with is to put it back into unstable (or
> > > even just experimental), but never let it propagate to testing. Then
> > > backports.org can do mechanized backports of updates without being

> mechanized? No.

I meant it in the sense of "run a script to create a backport from a
particular testing/unstable release, as opposed to changing any source
package and upload it manually to backports.org". I would very much
assume that this is what currently happens with backports.org. At
least that's how we do backports in Ubuntu, with "backport-source.py
package_name source_release".

I didn't mean "automatically move every -8.2 unstable upload to
-backports", of course.

> Only if they are tested carefully.

Goes without saying.

> And I still don't like this.

--verbose ?

Thanks,

Martin

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

Hi,

Gerfried Fuchs wrote:
>  This is what formorer doesn't like, and honestly, as much as I would
> like to help getting things working again and support postgres users
> here, I have to agree with him.

What solution do you have in mind for people who want Postgres 8.2 on
debian etch (because they had it once it has been offered by backports)?
So far I've only read that you don't like what's proposed, but I'm
missing any kind of a proposal for a solution of the problem.

Regards

Markus Wanner

Hi,

Gerfried Fuchs wrote:
>  Upgrade to pg8.3, the same that users of testing would have to do. And
> learn to see that backported packages are a moving target that gets
> updated.

The problem only exists because upgrading is not an option. There are
lots of people *wanting* to stick with Postgres 8.2 for good reasons. As
long as you don't see and accept that as a problem, we keep talking
across each other.

>  pitti has made it clear that he can't reasonably support pg8.2 himself
> side-a-side for lenny. Your offer was there to help out with that
> approach but you don't seem to want to go that path neither. Don't blame
> me for that.

My offer is to support Postgres 8.2 even for etch, as a kind of a
"backport" (not in the sense of a Debian-backports.org-backport, but a
backport of "newer" software to Debian etch).

If that easily gives us Postgres 8.2 for lenny as well, even better! I
probably want Postgres 8.2 also for lenny, as soon as that becomes stable.

To help others in the same situation, I would like to offer these
packages via some half-ways official channel. That turned out to be
harder than I thought.

>> So far I've only read that you don't like what's proposed, but I'm
>> missing any kind of a proposal for a solution of the problem.
>
>  So far I've only read that you don't like what's proposed, but I'm
> missing any kind of a proposal from you for a solution of the problem.

Obviously we are talking about different problems. I'm talking about
making Postgres 8.2 available for etch, because that's what I need. I am
providing a solution to that problem in form of a custom repository on
www.bluegap.ch/debian.

Regards

Markus Wanner

* Scott Marlowe <scott.marlowe@gmail.com> [2008-10-06 18:07:39 CEST]:
> On Mon, Oct 6, 2008 at 9:34 AM, Markus Wanner <markus@bluegap.ch> wrote:
> > 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).

 Good to hear. Though I see another problem here, slony is always only
available for a single postgres version in the current packaging, so
that upgrading path isn't that easy as you make it sound... At least not
if you want to do it on a single system and not through two different
machines.

 So long. :)
Rhonda

* Martin Pitt <mpitt@debian.org> [2008-10-10 09:49:01 CEST]:
> Alexander Wirt [2008-10-10  7:02 +0200]:
> > mechanized? No.
>
> I meant it in the sense of "run a script to create a backport from a
> particular testing/unstable release, as opposed to changing any source
> package and upload it manually to backports.org". I would very much
> assume that this is what currently happens with backports.org. At
> least that's how we do backports in Ubuntu, with "backport-source.py
> package_name source_release".

 Erm, the source package _has_ to be changed, the version has to get
adapted and the likes, for a start, propably even build-dependencies.
And it's expected that people uploading their packages to backports
apply similar testing to their uploads than they do with uploads to
unstable.

> > Only if they are tested carefully.
>
> Goes without saying.

 mechanized didn't sound like that, to be honest.

> > And I still don't like this.
>
> --verbose ?

,----------------------> quote yourself <----------------------
| So a compromise I can live with is to put it back into unstable (or
| even just experimental), but never let it propagate to testing. Then
| backports.org can do mechanized backports of updates without being
| tied to the long lifecycle of Lenny. Would that be an acceptable
| compromise for all involved parties?
`----------------------> quote yourself <----------------------

 Backports are meant to sit between stable and testing so that people
can upgrade to the next stable release without any major headaches. If
you backport from "unstable (or even just experimental)" you lose this
approach totally and fail with what backports.org is trying to achieve.

 This is what formorer doesn't like, and honestly, as much as I would
like to help getting things working again and support postgres users
here, I have to agree with him.

 So long,
Rhonda

* Markus Wanner <markus@bluegap.ch> [2008-10-10 10:27:51 CEST]:
> Gerfried Fuchs wrote:
> >  This is what formorer doesn't like, and honestly, as much as I would
> > like to help getting things working again and support postgres users
> > here, I have to agree with him.
>
> What solution do you have in mind for people who want Postgres 8.2 on
> debian etch (because they had it once it has been offered by backports)?

 Upgrade to pg8.3, the same that users of testing would have to do. And
learn to see that backported packages are a moving target that gets
updated.

 pitti has made it clear that he can't reasonably support pg8.2 himself
side-a-side for lenny. Your offer was there to help out with that
approach but you don't seem to want to go that path neither. Don't blame
me for that.

> So far I've only read that you don't like what's proposed, but I'm
> missing any kind of a proposal for a solution of the problem.

 So far I've only read that you don't like what's proposed, but I'm
missing any kind of a proposal from you for a solution of the problem.

 Just because you personally don't like a proposal doesn't mean that
it's not there, and I don't want to start it all over again.

 As your company seem to have quite some interest in it, there might be
yet another proposal: How about hiring someone to support it properly?
Please notice again that all of us are working voluntary on it and that
we all usually are pretty tight set with our spare time. And no, I am
not proposing to pay me for doing so, I wouldn't accept it because it
definitely would look too fishy and might get me compared to some former
DPL behavior.

 So long,
Rhonda

Markus Wanner schrieb am Donnerstag, den 09. Oktober 2008:

> Hi,
>
> Martin Pitt wrote:
> > That's in fact the option I have most trouble with. Reason is that
> > major upstream releases are roughly maintained for five years. All
> > packages in Lenny main will be supported for Lenny's lifetime, which
> > is in the order of 4 years (time to release plus, say, 3 years until
> > the next Debian release comes out, plus one year of "oldstable"
> > security/bug fix support).
>
> Understood.
>
> > However, postgresql-8.2 is already a little less than 2 years old,
> > which means that we will need to backport patches in Debian for over a
> > year. I think it will just barely work with supporting 8.1 in Etch and
> > 8.3 in Lenny, but 8.2 will mean trouble. That's the primary reason
> > why I only want to support the latest version in a stable release. I
> > just can't commit to doing all that backporting work myself.
>
> I didn't mean to put more work on your shoulders. Quite the opposite, in
> fact.
>
> > So a compromise I can live with is to put it back into unstable (or
> > even just experimental), but never let it propagate to testing. Then
> > backports.org can do mechanized backports of updates without being
mechanized? No.
Only if they are tested carefully. And I still don't like this.

Alex
--
Alexander Wirt, formorer@formorer.de
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A

On Fri, Oct 10, 2008 at 2:23 AM, Gerfried Fuchs <rhonda@deb.at> wrote:
> * Scott Marlowe <scott.marlowe@gmail.com> [2008-10-06 18:07:39 CEST]:
>> On Mon, Oct 6, 2008 at 9:34 AM, Markus Wanner <markus@bluegap.ch> wrote:
>> > 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).
>
>  Good to hear. Though I see another problem here, slony is always only
> available for a single postgres version in the current packaging, so
> that upgrading path isn't that easy as you make it sound... At least not
> if you want to do it on a single system and not through two different
> machines.

This is certainly not true for slony on ubuntu.  On Ubuntu there's a
slony1-bin package that has the common files, and then there's
postgresql-8.x-slony1 package for each pgsql version that has the
scripts to make that version happy.

Scott Marlowe [2008-10-10 15:43 -0600]:
> This is certainly not true for slony on ubuntu.  On Ubuntu there's a
> slony1-bin package that has the common files, and then there's
> postgresql-8.x-slony1 package for each pgsql version that has the
> scripts to make that version happy.

The only difference in Ubuntu is the fix for
http://bugs.debian.org/499548 (missing dependency) which hasn't been
applied in Debian yet.

The slony1 package indeed DTRT, it builds postgresql-X.Y-slony1. Thus
if you upgrade from e. g. an 8.1 system, the -8.1-slony package will
stick around, and you can install postgresql-8.3 and
postgresql-8.3-slony1 to do the upgrade.

Martin

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pitt a écrit :
> 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
>

Any plan for 8.4 pre-beta package ? (Devrim Gunduz provide usefull rpm package,
I'd like to have the same in debian).

Can it be in the experimental repository ?

- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm9h/kACgkQo/dppWjpEvx9SACfVd+hFon1lRqe41sDS9avjAsU
pYcAnRz89iHwyqwDpHVrRRO4Wz9aKoM5
=sPVB
-----END PGP SIGNATURE-----

Cédric Villemain [2009-03-15 23:58 +0100]:
> Any plan for 8.4 pre-beta package ? (Devrim Gunduz provide usefull rpm package,
> I'd like to have the same in debian).
>
> Can it be in the experimental repository ?

So far I usually started packaging those with the first public beta
version, but if we are close to that, sure. Packaging this is probably
easy, it just needs some time to get all the bits in postgresql-common
right (like correctly rewriting obsolete/removed/retyped configuration
settings, and the like).

I'll see to packaging a current snapshot soon.

Martin

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pitt a écrit :
> Cédric Villemain [2009-03-15 23:58 +0100]:
>> Any plan for 8.4 pre-beta package ? (Devrim Gunduz provide usefull rpm package,
>> I'd like to have the same in debian).
>>
>> Can it be in the experimental repository ?
>
> So far I usually started packaging those with the first public beta
> version, but if we are close to that, sure. Packaging this is probably
> easy, it just needs some time to get all the bits in postgresql-common
> right (like correctly rewriting obsolete/removed/retyped configuration
> settings, and the like).
>
> I'll see to packaging a current snapshot soon.
>
> Martin
>

Xcellent Martin. If I can help, ping me.

Here is the announce from Devrim :
http://archives.postgresql.org/pgsql-announce/2009-03/msg00012.php

And more particulary about !production:
http://yum.pgsqlrpms.org/news-8.4devel-ready-for-testing.php



- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm+EDsACgkQo/dppWjpEvwftwCgvaCgY6XdFethA449EFCsxqG+
LnUAmgM9h8N3OTzlIGkg05dsWEcdse+N
=1gdr
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cédric Villemain a écrit :
> Martin Pitt a écrit :
>> Cédric Villemain [2009-03-15 23:58 +0100]:
>>> Any plan for 8.4 pre-beta package ? (Devrim Gunduz provide usefull rpm package,
>>> I'd like to have the same in debian).
>>>
>>> Can it be in the experimental repository ?
>> So far I usually started packaging those with the first public beta
>> version, but if we are close to that, sure. Packaging this is probably
>> easy, it just needs some time to get all the bits in postgresql-common
>> right (like correctly rewriting obsolete/removed/retyped configuration
>> settings, and the like).
>
>> I'll see to packaging a current snapshot soon.
>
>> Martin
>
>
> Xcellent Martin. If I can help, ping me.
>
> Here is the announce from Devrim :
> http://archives.postgresql.org/pgsql-announce/2009-03/msg00012.php
>
> And more particulary about !production:
> http://yum.pgsqlrpms.org/news-8.4devel-ready-for-testing.php
>
>
>

I have started some work on that.
Old "debian/" updated to 8.4 (and the patches). But I keep on trouble with the
postgresql-doc.

Upstream have updated to autoconf 2.61 (git
82cd478cf80f4a5a50d39cb9e90a48823679e6a1), it is perhaps the issue : I have
replace the --with-docdir by the standard --docdir (new configure option).

And dh_install fail (because no files in the doc-8.4/html/). I tryed manualy the
suggested 'make -C doc all' as suggested by the GNUMakefile, but the doc is not
built.

Any tips are welcome.


- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknQmicACgkQo/dppWjpEvxjMACfUobjmCq1XJla/ewHQ2EBNbEc
CEwAoJFFEUC3rfBGbOLfnHkY2NDWRy8W
=aedw
-----END PGP SIGNATURE-----

Hello Cédric,

Cédric Villemain [2009-03-30 12:08 +0200]:
> I have started some work on that.

Whoops, sorry. So did I yesterday evening. I just fixed the branch
enough to build now [1].

I just need to update postgresql-common to work with 8.4. Some things
changed, e. g. pg_controldata doesn't report the default locale any
more, thus I need to rework the locales checks on startup.

Once the entire postgresql-common test suite passes, I'll upload this
to experimental.

Thanks,

Martin

[1] http://bazaar.launchpad.net/~pitti/postgresql/debian-8.4/files

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