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