On Thu, Dec 12, 2002 at 09:42:55AM -0600, John Goerzen scribbled: > On Thu, Dec 12, 2002 at 04:15:24PM +0100, Marek Habersack wrote: > > > > 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. > > It's unfair to demand that a maintainer of a complex package test every > possible situation prior to uploading. That could take literally weeks for Testing this particular thing would take a couple of minutes. Conducting all simple tests before uploading the package would leave only the non-trivial bugs to deal with. [snip] > > > 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? > > Just because you can take out an individual component and hold it up as "not > complex" does not mean that the sum of thest "not complex" components is > not itself complex. OK, but what's wrong in my suggestion to test the code that was added to handle simple and trivial situation? Is what you're saying that the complexity of package means that it should not be tested at all by the maintainer but simply uploaded to unstable for others to test 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 > > And you are purposely glossing over the facts. > > The Postgres that the new .debs install can NOT handle the previous format. You are glossing over the facts now. The deb contains a script to upgrade the previous format to the new one. The upstream contains code to perform that upgrade which is used by the mentioned script. Both the script and the upstream software failed to upgrade the data from the previous format to the new format. That makes the package unusable, because what's the use of database software which cannot handle your data? > > the old format data to the location where postgres expects to find it would > > take care of testing the data upgrade consistency. > > No, you have to still have something that can read the old format. True, you got me here. Note however that in this case the 7.3 package failed to accept the database dump, the older package didn't fail to create the dump. And keeping the database dumps doesn't require keeping any additional software. It is fairly safe to assume that the existing software (the previous version) can successfully create the dump of its database. So the remaining concern is to make sure that the new software can import the dump. And that's what failed in this case. > > > 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. > > It is not the domain of every maintainer to exercise superhuman perfection > when writing code. No, of course, that's why the code has to be tested, no? In your $$ work - do you write some code and never compile it before handing it over to your co-workers? > > > 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. > > Sometimes I am stunned by ignorance. No, this has nothing to do with > anything in /var. I beg your forgiveness for not knowing every damned thing. I'm not the maintainer of postgres, remember? I'm pretty much positive I would be stunned by your ignorance if I asked you how does Pike handle native code in the dumped modules. > It is a matter of configuring the files in /etc such that, for the purposes > of the upgrade only, the upgrade process has full access to do what it needs > -- AND to set up an environment suitable for the old version of postgres to > dump out its database, and then to change it so that the new version can > load the database from the dump. Do you need all that if you have a dump in the old format lying on your disk? Or whether in such case all you need to do is to simply import the existing dump? Again, _importing_ the dump failed with the 7.3 packages, not dumping. > It's also a matter of preserving old binaries in /usr/bin, executing things > from paths that they are not normally executed from, etc. Again, is it needed when you have the dump ready? > > 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 > > Oh yes, it's very convenient to get annoyed when you define every upgrade to Not every. The postgres package which I reported the bug for was the third in a row (or fourth, I don't remember) that failed. > be "simple." <sarcasm> Yes, I imagine that it should be trivial to upgrade from a.out > to ELF. And I see nothing difficult about changing from libc5 to libc6 -- > it's just an updated library. </sarcasm> > > That's ludicrous. Yes, and this thread became ridiculous. I wish I have never posted anything. I should've learned that posting to debian-devel anything that's not in accordance with the popular opinion leads to a stupid flamewar. > I'd like to see you come up with a better way to do it. Me? Why me? You yourself said I'm ignorant. > Not that I have any confidence that you could, since you obviously don't > even know what goes in to doing that upgrade. Right. > > > 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. > > Yes, and somebody else may have had just 7.1 installed, and someone else > just 6.5. What makes "your" version special? That it was the PREVIOUS version coming from the same maintainer. That's what makes it special. > > 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 > > Then what are you doing with all this childish whining in -devel? You could "Childish whining". Why is everything you don't like a childish whining? I don't and didn't like your childish whining about non-free in Debian and so what? > have submitted a patch in less time. If you actually had a clue what > Postgres was doing, that is. Right, now you're getting personal. Suit yourself. > > 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 > > I'm not talking about Mozilla, just about Postgres. Exactly. You picked up one thing that was not at all the point of my original mail. You chose to talk about that particular thing and the whole point of my mail got lost in your ranting that I'm too dumb and ignorant. Thank you. > > > I'm trying :) And I don't mind bugs, I mind stupid and silly bugs. > > What other kind of bug is there? None. All are the result of my ignorance. marek
Attachment:
pgpzVlEzp1ysn.pgp
Description: PGP signature