XPost: linux.debian.bugs.dist 
 From: vdanjean@debian.org 
  
 Package: debootstrap 
 Version: 1.0.141 
 Severity: wishlist 
  
   Hi, 
  
   While preparing a Linux Install Party, I tried to setup a DVD composed of 
 the 
 official trixie DVD-1 but also all packages in trixie-update and 
 trixie-security 
 since the release. 
   I did it just before the 13.1 release, I worked great. Security and update 
 packages were added on the DVD of the 13.0 release and no network download 
 was 
 required during the LIP (the network was a bootleneck where I was). 
  
   I used the same scripts a few days ago, with the official trixie 13.1 and 
 adding again trixie-update and trixie-security packages. But, this time, it 
 failed during the installation of the base system with the following error: 
 I: Unpacking the base system... 
 W: Failure trying to run: chroot "/target" dpkg --force-overwrite 
 --force-confold --skip-same-version --install 
 W: See /target/debootstrap/debootstrap.log for details 
  
 And, in the log: 
 [...] 
 dpkg: error: --install needs at least one package archive file argument 
  
 Type dpkg --help for help about installing and deinstalling packages [*]; 
 Use 'apt' or 'aptitude' for user-friendly package management; 
 Type dpkg -Dhelp for a list of dpkg debug flag values; 
 Type dpkg --force-help for a list of forcing options; 
 Type dpkg-deb --help for help about manipulating *.deb files; 
  
 Options marked [*] produce a lot of output - pipe it through 'less' or 
 'more' ! 
  
  
   I found it very strange. I tried to manually divert "dpkg" in the target 
 replacing it by a script that just returns if the last argument was 
 '--install' (else it called the real dpkg), but the installer was in fact 
 in a 
 loop on this call. 
  
  
   As my scripts to update the DVD were working a few days ago, I tried 
 to identify the problem. And, indeed, I found the problem: my scripts 
 were just concatenating the main/binary-amd64/Packages file of the DVD 
 and the main/binary-amd64/Packages file of trixie-update (that I got 
 with reprepro). By doing so, the upgraded packages are present several 
 times (with different versions) in the Packages file. Removing the 
 previous *systemd* entries, keeping only the ones from trixie-update 
 solved the problem. 
  
   This evening, I looked more in details in the debootstrap code. 
 I think that the root of the problem is that, in the 
 "Unpacking the base system...", in the while loop: 
 - get_next_predep calls "dpkg --predep-package" that, in this case, 
   returns the stanza for libsystemd-shared=257.8-1~deb13u2 (the version 
   from trixie-update) 
 - but "debfor libsystemd-shared" returns 
   /var/cache/apt/archives/libsystemd-shared_257.8-1~deb13u1_amd64.deb 
   i.e. the package for libsystemd-shared=257.8-1~deb13u1a (the version 
   from trixie 13.1). And indeed, /target/debootstrap/debpaths only 
   contains this path for libsystemd-shared 
 - so, at the next loop, get_next_predep still get the stanza for 
   libsystemd-shared=257.8-1~deb13u2, but the predep computation removes 
   libsystemd-shared from the list (as libsystemd-shared is now in 
   $done_predeps), and "in_target dpkg [...] --install" is called with an 
 empty 
   $predep, leading to the failure. 
  
  
   Now that I've found the root of this issue, I'm not sure it needs a fix. 
 It 
 would be perfectly reasonable for debootstrap to require a Packages file 
 without several versions of a package, at least for packages installed with 
 a manual dependency computation (when apt is used latter, there are no 
 problem 
 anymore with duplicate package entries with different versions). If you 
 think 
 so, feel free to close this bug. Nevertheless, this bug can give an 
 explaination why this message sometimes occurs during the installation. I 
 found 
 it on some webpages but only as a problem without any explaination (why this 
 message occurs and how to avoid this situation) 
  
   Regards, 
     Vincent 
  
 PS: I successfully reproduced the problem by running the installer binaries 
 in 
 a chroot. However, when trying to run the same scripts without the chroot 
 (setting DEBOOTSTRAP_DIR to point to the same scripts), I observe that 
 libsystemd-shared=257.8-1~deb13u2 is directly installed. So, with multiple 
 versions, the choosen version probably depends on more factors that I 
 identified. 
  
  
 -- System Information: 
 Debian Release: forky/sid 
   APT prefers stable-updates 
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') 
 Architecture: amd64 (x86_64) 
 Foreign Architectures: i386, armel 
  
 Kernel: Linux 6.12.41+deb13-amd64 (SMP w/4 CPU threads; PREEMPT) 
 Kernel taint flags: TAINT_OOT_MODULE 
 Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not 
 set 
 Shell: /bin/sh linked to /usr/bin/dash 
 Init: systemd (via /run/systemd/system) 
  
 Versions of packages debootstrap depends on: 
 ii  distro-info  1.14 
 ii  wget         1.25.0-2 
  
 Versions of packages debootstrap recommends: 
 ii  arch-test               0.22-1 
 ii  debian-archive-keyring  2025.1 
 ii  gpgv                    2.4.8-3 
 ii  mount                   2.41.1-1 
 ii  sqv                     1.3.0-3 
  
 Versions of packages debootstrap suggests: 
 ii  binutils                2.45-4 
 pn  squid-deb-proxy-client   
 pn  ubuntu-archive-keyring   
 ii  xz-utils                5.8.1-1 
 ii  zstd                    1.5.7+dfsg-1 
  
 -- no debconf information 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)