Package: src:linux,src:supermin,src:sbuild Severity: serious Justification: Breaks other packages X-Debbugs-Cc: sanv...@debian.org
Dear maintainers: I think this is a bug in linux, but I'm not 100% sure. Please do agree with the other maintainers on which package is to blame. I'm building packages for stretch using sbuild and a stretch chroot. The machine itself is also running stretch (it's a qemu virtual machine, but this is irrelevant here). When I build the supermin package, linux-image-amd64 is installed as a build-dependency. When the package has been built and the build-dependencies are removed afterwards, this is what happens: ------------------------------------------------------------------------ [...] Removing linux-image-amd64 (4.5+73) ... Removing linux-image-4.5.0-2-amd64 (4.5.4-1) ... Aborting removal of running kernel image. dpkg: error processing package linux-image-4.5.0-2-amd64 (--purge): subprocess installed pre-removal script returned error exit status 1 [...] Errors were encountered while processing: linux-image-4.5.0-2-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. Failed to remove installed packages! ------------------------------------------------------------------------ When I build any other package with sbuild after this one, this is what happens: +------------------------------------------------------------------------------+ | Update chroot | +------------------------------------------------------------------------------+ Hit:1 http://httpredir.debian.org/debian stretch InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: linux-image-4.5.0-2-amd64 : Depends: kmod but it is not installed Depends: linux-base but it is not installed Depends: initramfs-tools (>= 0.110~) but it is not installed or linux-initramfs-tool E: Unmet dependencies. Try using -f. -------------------------------------------------------------------------------- i.e. every other package fails from this point. The chroot is broken and it requires manual intervention to be fixed. The reason for this, I think, is that linux-image refuses to be uninstalled if it detects that it's the same version which is running in the system. This check, however, fails to account this case, where the linux-image being removed is the same version but not actually the same which is running, I think it should not be too much difficult to check that we are not in a chroot. If we are in a chroot, removing the package should succeed, even if the version matches the linux-image running in the ssystem. Alternatively (and this is where the bug would not be only a bug in linux), linux-image could provide some kind of escape mechanism allowing sbuild to uninstall it successfully. Alternatively, supermin should not build-depend on linux-image. (But I am nobody to tell people what they should build-depend on). [ Note about the severity: It is my understanding that sbuild is basically the same software which is running in the buildds, so the main reason this bug has not happened there is that they are still running jessie. But once that they are upgraded to stretch (and we can assume that they will, sooner or later), this could happen in the official autobuilders as well, and that's why I think this should be fixed before the release of stretch ]. Thanks.
