Re: Bug#302995: gettext: ftbfs on sparc

[Santiago Vila <sanvila@unex.es>]

retitle 302995 fastjar: postinst does not check for errors
reassign 302995 fastjar
severity 302995 serious
thanks

On Mon, 4 Apr 2005, Scott James Remnant wrote:

> On Mon, 2005-04-04 at 02:13 +0200, Santiago Vila wrote:
> 
> > On Sun, 3 Apr 2005, Blars Blarson wrote:
> > 
> > > gettext failed to build from source on the sparc buildd, however it
> > > built fine on my sparc pbuilder.  The buildd log lacks some things
> > > that are in the pbuilder log "config.status: creating
> > > intl-java/Makefile" "config.status: creating intl-csharp/Makefile"
> > > and of course the sections that use those makefiles.
> >
> > A diff between the build logs for 0.14.2-1 and 0.14.3-1 for sparc
> > yields the following meaningful difference:
> > 
> > -checking for jar... jar
> > +checking for jar... no
> > 
> > So there was no /usr/bin/jar in the sparc autobuilder after installing
> > the fastjar package, but /usr/bin/jar is handled via the alternatives
> > mechanism. Seems like a dpkg bug to me.
>
> What makes you think this is a dpkg bug?

Mainly, the fact that I have seen other packages fail to build because
of the alternatives handling (see for example, the two failed builds
for mips for original-awk_2004-12-22-1).

In this particular case, however, I've just realized that there is a
problem in the postinst of fastjar, since it does:


update-alternatives [...] || true


This is against policy:

   The package management system looks at the exit status from these
   scripts. It is important that they exit with a non-zero status if
   there is an error, so that the package management system can stop its
   processing. For shell scripts this means that you almost always need
   to use set -e (this is usually true when writing shell scripts, in
   fact). It is also important, of course, that they don't exit with a
   non-zero status if everything went well.

Reassign again.