Package: apt
Version: 2.6.1
Severity: wishlist
Control: affects -1 + mmdebstrap
Hi David,
do you remember our conversation in #debian-dpkg from 2018?
} elsif ($options->{variant} eq 'apt') {
# if we just want to install Essential:yes packages, apt and their
# dependencies then we can make use of libapt treating apt as
# implicitly essential. An upgrade with the (currently) empty status
# file will trigger an installation of the essential packages plus apt.
#
# 2018-09-02, #debian-dpkg on OFTC, times in UTC+2
# 23:39 < josch> I'll just put it in my script and if it starts
# breaking some time I just say it's apt's fault. :P
# 23:42 < DonKult> that is how it usually works, so yes, do that :P (<-
# and please add that line next to it so you can
# remind me in 5+ years that I said that after I wrote
# in the bugreport: "Are you crazy?!? Nobody in his
# right mind would even suggest depending on it!")
@dl_debs = run_apt_download_progress({
APT_ARGV => ['dist-upgrade'],
dryrun => $options->{dryrun},
},
);
Well, it is now even six years later. It is time!
The problem first showed up yesterday in the sbuild autopkgtest for riscv:
https://ci.debian.net/data/autopkgtest/testing/riscv64/s/sbuild/47087233/log.gz
Log is also attached for when it gets deleted from ci.d.n but the important
bits are these:
MarkInstall util-linux:riscv64 < none -> 2.40.1-2 @un uN Ib > FU=0
Installing libblkid1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libblkid1:riscv64 < none -> 2.40.1-2 @un uN > FU=0
Installing libcap-ng0:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libcap-ng0:riscv64 < none -> 0.8.5-1 @un uN > FU=0
Installing libcrypt1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libcrypt1:riscv64 < none -> 1:4.4.36-4 @un uN > FU=0
Installing libmount1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libmount1:riscv64 < none -> 2.40.1-2 @un uN > FU=0
Installing libpam0g:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libpam0g:riscv64 < none -> 1.5.3-7 @un uN Ib > FU=0
Installing libaudit1:riscv64 as Depends of libpam0g:riscv64
libaudit1:riscv64 Depends on libaudit-common:riscv64 < none | 1:3.1.2-2 @un uH > (>= 1:3.1.2-2.1) can't be satisfied!
libpam0g:riscv64 Depends on libaudit1:riscv64 < none @un H > (>= 1:2.2.1) can't be satisfied! (dep)
util-linux:riscv64 PreDepends on libpam0g:riscv64 < none @un H > (>= 0.99.7.1) can't be satisfied! (dep)
[...]
Setting up usrmerge (39) ...
Can't exec "mountpoint": No such file or directory at /usr/lib/usrmerge/convert-usrmerge line 431.
Failed to execute mountpoint -q /lib/modules/: No such file or directory
E: usrmerge failed.
dpkg: error processing package usrmerge (--install):
installed usrmerge package post-installation script subprocess returned error exit status 1
Because apt decides not to install util-linux, the usrmerge postinst fails.
This all boils down to mmdebstrap using the funny "apt dist-upgrade" trick to
let apt choose all the Essential:yes packages plus itself for the mmdebstrap
"apt" chroot variant.
How hard would it be to let apt dist-upgrade fail if it is unable to install an
Essential:yes package?
This bug is certainly wishlist and might as well be marked as wontfix without
much value being lost. But I thought that given your comment back in 2018
including your spot-on prediction (only off by one year!) I should absolutely
share this with you. :)
Thanks!
cheers, josch
Attachment:
47087233.gz
Description: application/gzip