[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?

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

> 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

> 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.


Attachment: pgpQdzYYY5H1N.pgp
Description: PGP signature

Reply to: