I would not be surprised. Everything I did I tested on one or two installs but very well could have missed corner cases. Go ahead and make a ticket for this.
Sent from my phone, so pardon the typos and brevity. On Sep 25, 2012 12:01 PM, "Ed Kohlwey" <[email protected]> wrote: > While trying to install the native packages today on Ubuntu I found at > least one bug in the package scripts and what I think may be another. > > I was wondering how well tested the scripts are? > > First, the postinst script reads: > > if [ -z $JAVA_HOME -o ! -f $JAVA_HOME/jre/bin/ ] ; then > JAVA_HOME=`readlink -f /usr/bin/java` > JAVA_HOME=`dirname $JAVA_HOME` > JAVA_HOME=`cd $JAVA_HOME/../../; pwd` > fi > > if JAVA_HOME is unset, however, the script will fail because somehow two > arguments are passed to -f. It should read: > > if [ -z "$JAVA_HOME" -o ! -f "$JAVA_HOME/jre/bin/" ] ; then > JAVA_HOME=`readlink -f /usr/bin/java` > JAVA_HOME=`dirname $JAVA_HOME` > JAVA_HOME=`cd $JAVA_HOME/../../; pwd` > fi > > After fixing the quote problem, I'm still getting this error from dpkg > itself: > > (Reading database ... 128812 files and directories currently installed.) > Preparing to replace accumulo-native 1.4.1 (using > accumulo-native_1.4.1-amd64.deb) ... > Unpacking replacement accumulo-native ... > Setting up accumulo-native (1.4.1) ... > cd: 25: can't cd to /usr/lib/accumulo/src/server/src/main/c++ > make: *** No targets specified and no makefile found. Stop. > dpkg: error processing accumulo-native (--install): > subprocess installed post-installation script returned error exit status 2 > Errors were encountered while processing: > accumulo-native > > After investigating the error I've found that dpkg seems to make all the > new files in directories with the suffix .dpkg-new, and then it renames > them at some point. I was unable to determine via a casual google if this > should happen before or after the postinst script is run, but I'm wondering > if the assumption that the makefile and its dependencies will have their > normal names is an error. > > Either way, that shouldn't cause the cd command to fail (although it might > cause the subsequent 'make' command to fail). I'm unsure at this point why > cd is failing because it appears that dpkg unpacks the data.tar.gz file > (although with its contents renamed), which I determined from running ls > while dpkg is running. > > Anyone have any ideas? >
