Re: status of postgresql for sarge?
On Mon, 2004-03-08 at 10:15, Martin Schulze wrote: Re new upstream package, it would be *very* nice if you would be able to test and smoothen the upgrade path from woody-pg to sarge-pg (sid-pg) as well. I've done a release upgrade before which resulted in a complete desaster with the daemon not even starting. I've heard reports from other people who experienced at lest critical problems with an upgrade as well, contrary to my hope that my problems were triggered by sunsport or something less common. In order to smooth the upgrade path we would really need to change the woody package; this is not a security issue, so it falls outside normal policy for woody updates. The problem is that the current upgrade seeks to use the binary of the old package to do a dump of the database contents. Once upon a time, this was done in the preinst, but with the introdcution of apt, that became impracticable, because apt would often remove the old package before the new package's preinst could run. At present the prerm script saves the binaries for use by the postinst of the new package. Since there have been so many changes since woody, it is now possible for libraries necessary for the old binaries to run to be removed by apt as well, therefore even though the old binaries have been preserved, they will not run. In order to cure this, we need to change the woody package, either to force it to do a dump in the prerm or to save all the shared libraries it needs to go with its binaries for use by the new package's postinst. Even then, there will be problems for those who don't upgrade woody. The best solution will be the new PostgreSQL package structure I am working on, but I am not ready to release that yet. -- Oliver Elphick olly@lfix.co.uk LFIX Ltd
Re: status of postgresql for sarge?
Oliver Elphick wrote: In order to cure this, we need to change the woody package, either to force it to do a dump in the prerm or to save all the shared libraries it needs to go with its binaries for use by the new package's postinst. Even then, there will be problems for those who don't upgrade woody. The best solution will be the new PostgreSQL package structure I am working on, but I am not ready to release that yet. IFF a change to the woody package is small and will help future upgrades to sarge (and not affect upgrades in woody itself), I could be persuaded to include such an update in a point release through proposed-updates. This could even be classified as 'prevents data loss'. Hence, if you are able to provide proper adjustments for the packages in woody to smoothen the upgrade path, please prepare a patch and discuss this with me (off-list should be enough). Having the prerm do the dump, sounds more appropriate to me than saving a binary and tons of libraries. Regards, Joey -- Linux - the choice of a GNU generation.
Re: status of postgresql for sarge?
On Mon, Mar 08, 2004 at 02:58:07PM +, Oliver Elphick wrote: In order to cure this, we need to change the woody package, either to force it to do a dump in the prerm or to save all the shared libraries it needs to go with its binaries for use by the new package's postinst. Afaik, It's recommended to use the pg_dump(all) from the new release to dump the old database. This would mean that you need binaries from both versions at the same time. Kurt
Re: status of postgresql for sarge?
Martin Pitt writes: Hi Matthias! On 2004-03-06 17:14 +0100, Matthias Klose wrote: postgresql still has one RC report open, which was marked pending on 24 Feb by Martin Pitt. Right, our current CVS fixes some ten bugs, amongst them the RC bug. Are there plans to make the pending upload? When? postgresql currently blocks some more packages. According to Oliver (the primary maintainer) there will be a new bugfix upstream release soon, which would be a good opportunity to upload an updated package. If the upload is not made ... postgresql had two RC reports, which are fixed in unstable (versioned shlibs dependency), and which allowed other packages enter testing (libpqxx-2.1.3, pygresql). Is it ok to make uploads directly for testing to fix the non-working packages (undefined symbols in libpq3 library)? Is that really possible? Some time ago I asked on d-devel for this [1], but never really got a satisfying answer. Nevertheless, I would not dare to put the new postgresql directly into testing. No, the proposal was to fix the broken packages libpqxx-2.1.3, pygresql with a direct upload to testing. As Colin said, an update of postgresql, which fixes the RC report, maybe with priority medium, and then migrates to testing in five days is the preferred solution. The automatic upgrading is still broken; a longer-term solution is progressing, but far from being ready for shipment. OTOH, if the upload doesn't fix the RC report and it was already broken in sarge, then maybe downgrade the severity and let it go to testing as it is now? Matthias
Re: status of postgresql for sarge?
On Sun, 2004-03-07 at 00:19, Colin Watson wrote: According to Oliver (the primary maintainer) there will be a new bugfix upstream release soon, which would be a good opportunity to upload an updated package. It would be very nice to have this update, or an earlier one, well on its way into testing by the time of the projected base freeze (15th March). Its current brokenness is a problem, so if we can avoid waiting for upstream then that would be helpful. The new upstream package is a bugfix release and is expected within a week, but I don't object to uploading the current CVS now. Martin will have to do it, because my new key is still not in the keyring. Oliver
Re: status of postgresql for sarge?
Hi! On 2004-03-07 9:28 +0100, Matthias Klose wrote: As Colin said, an update of postgresql, which fixes the RC report, maybe with priority medium, and then migrates to testing in five days is the preferred solution. Okay, I will do that. OTOH, if the upload doesn't fix the RC report and it was already broken in sarge, then maybe downgrade the severity and let it go to testing as it is now? No, the current RC bug in particular is fixed (we just got another one today, I will see what we can do about it). The automatic upgrading is flawed in general; this affects both the testing and the Sid version. postgresql tries to keep binaries from a previous version to be able to dump the database and then restores it in the new format; however, as the newest RC BR (and many many others) show, there may be libraries which changed or disappeared which make the automatic upgrade break. Before you ask: there were already versions which tried to dump in the preinst (with the old binaries still present), but that was flawed as well since other packages may already be replaced. Oliver is working at a new architecture which will allow several major versions be installed in parallel; this will eventually solve all troubles, but it is not finished yet. In this sense the current is no better or worse than the one in Sarge. But the current version fixes many other bugs that are still in testing, so I think it is worth uploading. I don't have time to do it today, but I will care for that tomorrow. Have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: status of postgresql for sarge?
On Sun, Mar 07, 2004 at 05:08:39PM +0100, Martin Pitt wrote: The automatic upgrading is flawed in general; this affects both the testing and the Sid version. So tag it properly. -- 2. That which causes joy or happiness.
Re: status of postgresql for sarge?
On Sat, Mar 06, 2004 at 05:14:24PM +0100, Matthias Klose wrote: postgresql still has one RC report open, which was marked pending on 24 Feb by Martin Pitt. Are there plans to make the pending upload? When? postgresql currently blocks some more packages. If the upload is not made ... postgresql had two RC reports, which are fixed in unstable (versioned shlibs dependency), and which allowed other packages enter testing (libpqxx-2.1.3, pygresql). Is it ok to make uploads directly for testing to fix the non-working packages (undefined symbols in libpq3 library)? We need the version of postgresql from unstable anyway to satisfy versioned dependencies from things like planner (a meta-gnome2 dependency which needs to be upgraded), so I would suggest concentrating effort elsewhere in this case. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: status of postgresql for sarge?
On Sat, Mar 06, 2004 at 07:43:15PM +0100, Martin Pitt wrote: On 2004-03-06 17:14 +0100, Matthias Klose wrote: Are there plans to make the pending upload? When? postgresql currently blocks some more packages. According to Oliver (the primary maintainer) there will be a new bugfix upstream release soon, which would be a good opportunity to upload an updated package. It would be very nice to have this update, or an earlier one, well on its way into testing by the time of the projected base freeze (15th March). Its current brokenness is a problem, so if we can avoid waiting for upstream then that would be helpful. Thanks, -- Colin Watson [EMAIL PROTECTED]
