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
