Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?
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
a single person to do. That is why we have this concept of UNSTABLE and
TESTING.
> > 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.
> 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.
> 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.
> > 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.
> > 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.
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.
It's also a matter of preserving old binaries in /usr/bin, executing things
from paths that they are not normally executed from, etc.
> 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
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.
I'd like to see you come up with a better way to do it.
Not that I have any confidence that you could, since you obviously don't
even know what goes in to doing that upgrade.
> > 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?
> 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
have submitted a patch in less time. If you actually had a clue what
Postgres was doing, that is.
> 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.
> I'm trying :) And I don't mind bugs, I mind stupid and silly bugs.
What other kind of bug is there?
Reply to: