[Pkg-postgresql-public] Postgres major version support policy on Debian
rhonda at deb.at
Tue Oct 7 17:11:56 UTC 2008
One (hopefully) last reply. :)
* Markus Wanner <markus at 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
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.
> "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
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
> > 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
> >> 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,
> > 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
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.
More information about the Pkg-postgresql-public