On Thu, Dec 12, 2002 at 08:31:01AM -0600, John Goerzen scribbled: > On Thu, Dec 12, 2002 at 01:08:37AM +0100, Marek Habersack wrote: > > Another case of an untested package. Going back to postgres - apparently the > > maintainer "has no time" to test upgrades from earlier formats of the > > This is really, really unfair. I agree, it's unfair not to test one's work. > The Postgres upgrade process is a very complex one, fraught with having to > keep binaries from previous packages around, setting up a Postgres execution > environment with the old version despite having the new version (with > possibly incompatible files) installed, etc. John, I do realize that, trust me. But I also realize that the case of missing postgresql.env file does NOT fall in the complex directory, does it? As for the upgrade process itself - keeping a chunk of a database in the previous format is not that complicated either. A single script which copies the old format data to the location where postgres expects to find it would take care of testing the data upgrade consistency. > These are things that our package framework does not make easy, particularly > the keeping binaries from the previous version. I agree, but look, in the case I reported it's the Debian postinst/prerm script that failed. So these were things that fall in the responsibility domain of every maintainer - to ascertain consistency of the code they write. > In order to do the dump and restore from dump, it also has to modify the > configuration to make sure its dumping processes have permissions to access > all the data. But isn't that what the postinst script in postgres does anyway? It's just a matter of replacing the data in /var/lib/postgresql/data - a symlink to the test area would do. > There are also interesting dump situations (where a plain dump doesn't > necessarily build a database the same as the old one) involving, if memory > serves, stored procedures and sequence types. John, yes, I realize that... But please, acknowledge the fact that the case I mentioned was NOT that hard. It was simple: upgrade from the 7.2 format to the 7.3 format failed. It failed not only in Debian but also upstream. If the package was tested in such a simple way, the bug would have never popped up. > In short, there are lots of corner cases, special cases, etc. that it may > not even be POSSIBLE for the maintainer to test. (How many old versions of > Postgres can you really have installed? Some versions people have installed > may not even exist in the Debian archive any more.) I had just 7.2 installed and the upgrade still failed. > And, as a disclaimer, I personally have been bitten by these postgres > upgrade bugs. Guess what -- I file bug reports and help Oliver find the > problem rather than childishly whining about it in debian-devel. While I'm > at it, I say to myself "I'm glad I'm not maintaining this" :-) John, in the meantime I have helped with 3 other packages (IIRC) plus I'm repackaging 5 versions of Pike (not a small package either), plus two versions of Caudium for 2 architectures and woody+sarge+sid. In addition I have to do the $$ work, too :) - I really, really lack time, otherwise I would be glad to help solving such silly mistakes as those I mentioned. But, still, such mistakes should not find their way to unstable (vide bonob-activation and mozilla-snapshot, for example). > > 2h of worktime to recover - if the package was tested by the maintainer > > Yes, maintainers should test packages before uploading them. Maintainers > are also human. If maintainers were able to catch all possible bugs before > uploading a package, there'd be no need for testing or for our BTS. I will repeat that ad nauseam - the bugs I've mentioned were all cases of "install to find out". Mozilla and bonobo-activation weren't tested, because if they were, the maintainer would have noticed that he cannot finish installing mozilla or he cannot login to GNOME, right? > Bugs exist. Get on with your life. I'm trying :) And I don't mind bugs, I mind stupid and silly bugs. regards, marek
Attachment:
pgpQdzYYY5H1N.pgp
Description: PGP signature