Control: severity -1 minor On Mon, 2014-12-01 at 21:27:18 -0800, Josh Triplett wrote: > On Tue, Dec 02, 2014 at 05:31:36AM +0100, Guillem Jover wrote: > > On Mon, 2014-12-01 at 20:14:55 -0800, Josh Triplett wrote: > > > Package: dpkg > > > Version: 1.17.22 > > > Severity: normal > > > > > > Preparing to unpack .../chromium_39.0.2171.71-1_amd64.deb ... > > > /var/lib/dpkg/tmp.ci/preinst: 6: /var/lib/dpkg/tmp.ci/preinst: upgrade: > > > not found > > > Unpacking chromium (39.0.2171.71-1) over (38.0.2125.101-3) ... > > > > > > I've seen such errors from maintainer scripts before, and they previously > > > showed the name of the package, rather than just a temporary dpkg path. > > > > That's because the script does not return with an error exit code, and > > as such I don't think dpkg can do much. This is the equivalent broken > > code: > > > > ,--- preinst --- > > #!/bin/sh > > set -e > > if "$1" = "upgrade"; then > > echo "action" > > fi > > `--- > > > > ,--- > > $ ./preinst upgrade; echo $? > > ./preinst: 3: ./preinst: upgrade: not found > > 0 > > `--- > > This would occur with any such error message generated by a maintainer > script, and it has nothing to do with the error exit code.
The point I was trying to make is that as long as the script does not return with an error exit code, then dpkg cannot reliably print an error message with the full information, including package name affected, architecture if needed, etc. And part of that information relies on whatever the involved interpreter decides to print, including (or not) the pathname to the script. > I seem to > recall maintainer scripts previously emiting such messages with the > actual name of the script, though it's possible that I didn't see such > messages from preinst scripts that get run before unpacking the package > to the filesystem (and thus have to run from a temporary location rather > than /var/lib/dpkg/info/). Yes, the pathname for the being unpacked maintscripts has not changed (ever?). > In any case, dpkg could improve the error message here by naming the > script in the temporary directory the same as it names scripts in > /var/lib/dpkg/info; in this case, /var/lib/dpkg/tmp.ci/chromium.preinst. Hmm, I'll think about it, because that means complicating the code for something that should (in principle) be obvious from the output context, and that should (in theory) never happen, as that's always a bug in the package. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
