Bug#845280: apt: useless path given in failed install messages
Package: apt Version: 1.3.1 Severity: normal Hi! When installation of a package fails, recent apt makes dpkg print useless paths in the error message: dpkg: error processing archive /tmp/apt-dpkg-install-iwKqmD/4-libxtables12_1.6.0+snapshot20161117-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libxtables.so.12.0.0', which is also in package libxtables11:amd64 1.6.0+snapshot20161117-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /tmp/apt-dpkg-install-iwKqmD/4-libxtables12_1.6.0+snapshot20161117-2_amd64.deb Until recently, the path given was to /var/cache/apt/archives/ where .deb files are actually kept. I see they are now copied to /tmp/apt-dpkg-install-iwKqmD/ and prefixed by ordinal numbers, but that temporary directory ceases to exist before apt returns, thus is useless to the user. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.10+ (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages apt depends on: ii adduser 3.115 ii debian-archive-keyring 2014.3 ii gpgv2.1.16-2 ii init-system-helpers 1.46 ii libapt-pkg5.0 1.3.1 ii libc6 2.24-5 ii libgcc1 1:6.2.1-4 ii libstdc++6 6.2.1-4 Versions of packages apt recommends: ii gnupg 2.1.16-2 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.18.15 ii powermgmt-base 1.31+nmu1 ii python-apt 1.1.0~beta5 -- no debconf information
Bug#845280: apt: useless path given in failed install messages
On Tue, Nov 22, 2016 at 06:50:34AM +0100, Adam Borowski wrote: > Until recently, the path given was to /var/cache/apt/archives/ where > .deb files are actually kept. I see they are now copied to > /tmp/apt-dpkg-install-iwKqmD/ and prefixed by ordinal numbers, but that > temporary directory ceases to exist before apt returns, thus is useless to > the user. s#copied#symlinked# but yes. The reason is simply that we avoid too long commandlines and allow dpkg some wiggle room in terms of ordering this way as we are able to just say "install all debs in this directory" then. APT is suggesting an order with the numbers still to avoid running into as of yet unfixed M-A:same and up/down breaks involving ordering bugs in dpkg. I don't see what we can be doing about this through. dpkg can't follow the symlinks directly as that would spoil the ordering suggestion apt (and perhaps others) make this way and order can be quite important – although it might decide that this isn't an interface it wants to support (given its kind of an accident it got introduced as this wasn't ordered until 1.18.5, but I got nonbinding IRC approval on using it…) which means we have to disable this again… :/ It could perhaps follow the symlinks in output only, but that would be wrong any time the symlink is part of the problem and also kinda ugly. It could do it only if it realizes that this is apt doing this, but… urgs I guess. On the other hand apt can't rewrite the error messages. We could keep the temporary directory in case of error, but likely the minute we do we get a bugreport that we leave temporary files around filling up peoples /tmp. And of course we could go willingly back to the old invocation style: // force apt to not use the --recursive invocation style dpkg::install::recursive "false"; dpkg::install::recursive::force "true"; So, lets let everyone pick his/her preferred poison and we will see who dies last in this vote… (cc'ed dpkg as they are as involved in it as apt is). Best regards David Kalnischkies signature.asc Description: PGP signature
