On Wed, Dec 11, 2002 at 08:29:33PM -0600, Steve Langasek scribbled:
> On Thu, Dec 12, 2002 at 02:53:15AM +0100, Marek Habersack wrote:
>
> > > you think "this is unstable" comments help, it's not fair for you to be
> > > mad at maintainers who HAVE done what they can to test packages before
> > Do you think mozilla-snapshot was installed by the maintainer before he
> > uploaded it? Or do you think that the postgres maintainer checked whether
> > upgrade from the 7.2 format to the 7.3 format works? If he installed the
> > package, he would have tested that functionality since I suppose he had 7.2
> > data on his disk before. I named postgresql as the example, because that
> > happened to be what triggerred my mail, that's it - no other reason. And,
> > again, I'm not mad about lost data (although I lost some data, not important
> > though) - I'm mad about recklessness and laziness of some maintainers.
>
> I won't defend any developer who did not install the package before
> uploading it. If it's clear that a maintainer script contains an error
> so serious that the package *would not install for anyone*, that's
That would be the bonobo-activarion and mozilla-snapshot cases, yep.
> unexcusable. It's different, though, when there's a bug that only
> affects *some* types of installation (upgrade vs. fresh install, upgrade
> from a particular version, conflicts with other packages). It can be
> quite time consuming to test all possible combinations, and often is not
> worth the effort.
True, as long as the bug is in the code that was in place for weeks or
months. But if the bug is in the code which has just been added to a
script/program - then the new code should be especially carefully tested by
the maintainer. And this is the case with postgresql. The maintainer added
code to test for missing /etc/postgresql/postgresql.env and restore it if
necessary - the bug was precisely in that code, which was never tested after
adding it. And in this case the test was trivial, really trivial - it was
sufficient to either move said file out of the way or install the whole
thing in a chroot.
> In reading the bug report you linked to, I understand that Oliver is
> claiming that he did install the package to test it. I haven't looked
If he did so, he must've noticed that the previous version of postgresql-dev
package has had a bug in its .postrm script - a bug that could've been fixed
in the newer version of the -dev package _if_ the newer version was ever
installed. To cover my words with facts, here's the .postrm script from the
buggy version (typing from memory, the path might be wrong):
#!/bin/sh
rm -f /usr/include/postgresql/libpq++.h
That's the whole script. In case when the file above is missing, postrm
fails and a recovery is attempted by using the new package's scripts. It
failed too. Now, if the maintainer did install the new package, he would've
included a fix for the above issue (i.e. handled the situation in the new
version of the package). The fix wasn't there. The original .postrm script
is an obvious and trivial error - such things should not happen. It might be
the lack of time Olivier mentions, I don't know - but I am worried by such
a state of matters.
> at the maintainer script, so I was taking him at his word. If you are
> saying that he could not have installed the package because of the bug,
> that's another issue.
That's my belief (I might be wrong, of course)
> As for upgrading from 7.2 to 7.3, I agree that's important, and I would
> hope all maintainers are aware of upstream changes like this, but I can
> also see how it's possible that just installing the package wouldn't
> catch the bug.
It would. A friend of mine tried to upgrade his 7.2 database using a version
of Postgresql compiled from the upstream tarball. The upgrade failed just
the same as with the debian package. That suggest an upstream bug which
could be caught if the package was tested (read - installed). This kind of
test is a crucial thing for database software. And saying in this case that
'hey, it's unstable, expect it to break' is just unacceptable.
> > Take for example this thing:
>
> > trap "mail -s "$MAILSUBJECT" root@localhost < ${MAILFILE}; rm -f $MAILFILE"
>
> > Do you honestly think that the maintainer installed script with that code
> > and that the code worked for him?
>
> I don't think that code worked for him. But without context, I don't
> know that this line isn't optional. If I put that line inside of an
> "if false" block, it appears to work fine for me.
Yes, true. But this is exactly the situation I described above - it's a new
code. New code must be tested. Period. There's no excuse to that.
> I've just downloaded the source package, and am looking at the line in
> question, which is bounded by:
>
> # If the conffile has been _deleted_, restore it from the dpkg-dist
> # version (deletion goes beyond valid user editing!)
> f=/etc/postgresql/postgresql.env
> if [ ! -f $f ]
> then
> # postgresql.env has been deleted; we must have it, but since
> # it is a conffile, we must ask
>
> and:
>
> fi
>
> The comments make it clear to me that, at least in this case, simply
> installing the package would not catch the bug. Do I think this code
True. But my above comment still holds.
> should have been tested before being added to the maintainer script?
> Sure. That doesn't mean I haven't also been guilty before of
> *believing* that a piece of code would work when it wouldn't. And you
> know, the changelog suggests that this line has been there since March
> 2002 -- so it must not have affected too many people!
I agree with you. But here we hit an issue of importance of the package -
postgresql is way to critical to be treated such recklessly.
> Maintaining a large server package like postgresql isn't easy, and I
> don't think we have enough developers who are willing to work on this
> kind of package. I don't want the developers we *do* have working on
> large packages to feel unappreciated and abandon them.
Oh, but that's not my intention. As I suggested twice alread - if time is
the issue, find helpers! And postgresql has been giving us many problems in
the past year or so. Therefore I do think that Olivier needs help - but
nobody can push him to ask for it.
> For packages that were never installed before upload, you're quite
> right, and those developers deserve whatever flames they get. :) I just
I hope not to have caused an impression of trying to raise a flamewar. It
wasn't and it is still not my intention at all.
> don't think that the postgres maintainer is currently one of them.
I beg to differ on that one, but that's my personal opinion based on
personal history of experiences with the postgresql package. Nothing
personal towards Olivier, though.
regards,
marek
Attachment:
pgp5eMcnsAGXl.pgp
Description: PGP signature