Bug#943986: wrong shared linkage position of mv's library dependency
On Mon, Nov 04, 2019 at 08:17:33AM -0500, Michael Stone wrote: > On Sat, Nov 02, 2019 at 12:51:41AM +0100, David Frey wrote: > > cp and mv have a runtime linkage to libacl and libattr which are > > installed in /usr/lib/x86_64-linux-gnu/. > > > > This means that a single-user booted system without mounted /usr, > > is not able to cp or mv files! > > > > Either the dependancy should be dropped, or the libacl and libattr > > shared libraries should be moved into /lib. > > I don't believe that operating without /usr is a current design goal for > debian. In my opinion it should be. It is very useful for system repair and restore. >From hier(7): /bin This directory contains executable programs which are needed in single user mode and to bring the system up or repair it. ... /lib This directory should hold those shared libraries that are nec‐ essary to boot the system and to run the commands in the root filesystem. Keyword is *run* the commands. Thanks, David reopen 943986
Bug#943986: wrong shared linkage position of mv's library dependency
Package: coreutils Version: 8.30-3 Severity: serious cp and mv have a runtime linkage to libacl and libattr which are installed in /usr/lib/x86_64-linux-gnu/. This means that a single-user booted system without mounted /usr, is not able to cp or mv files! Either the dependancy should be dropped, or the libacl and libattr shared libraries should be moved into /lib. Thanks, David -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=english (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages coreutils depends on: ii libacl1 2.2.53-4 ii libattr1 1:2.4.48-4 ii libc62.28-10 ii libselinux1 2.8-1+b1 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information Mit freundlichen Grüssen, David Frey --