(This is identical to Bug 27064 from waaaay back in 2003 ;) I've just had to perform recovery on a system with a separate /usr partition which hit a fsck-on-boot problem, and noticed that several binaries - some really key ones - installed into /bin or /sbin are linked against libraries on /usr, and are therefore unusable until the system can successfully complete localmount: $ for f in /bin/* /sbin/* $( sudo find /lib/ -type f -name \*.so\* ); do echo "$f"; sudo ldd $f 2>/dev/null | grep 'usr'; done | grep -B 1 'usr' /bin/arping libidn.so.11 => /usr/lib/libidn.so.11 (0xf7684000) -- /bin/expr libgmp.so.10 => /usr/lib/libgmp.so.10 (0xf7701000) -- /bin/login libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7512000) -- /bin/mail liblockfile.so.1 => /usr/lib/liblockfile.so.1 (0xf76bb000) -- /bin/nano libmagic.so.1 => /usr/lib/libmagic.so.1 (0xf76ea000) -- /bin/passwd libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7558000) -- /bin/ping libidn.so.11 => /usr/lib/libidn.so.11 (0xf76c2000) /bin/ping6 libidn.so.11 => /usr/lib/libidn.so.11 (0xf7707000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xf74e9000) -- /bin/rnano libmagic.so.1 => /usr/lib/libmagic.so.1 (0xf76e3000) -- /bin/su libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf757c000) -- /sbin/arptables-compat libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf75a1000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf7576000) /sbin/audispd libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf757f000) /sbin/audispd-zos-remote libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0xf7743000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xf7732000) libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7710000) libsasl2.so.3 => /usr/lib/libsasl2.so.3 (0xf7529000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xf74b4000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xf72ad000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf71a6000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7171000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7145000) /sbin/auditctl libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7506000) /sbin/auditd libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74f5000) -- /sbin/aureport libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75c5000) /sbin/ausearch libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74f2000) /sbin/autrace libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7526000) -- /sbin/cfdisk libfdisk.so.1 => /usr/lib/libfdisk.so.1 (0xf7692000) libslang.so.2 => /usr/lib/libslang.so.2 (0xf74c2000) -- /sbin/cryptsetup libcryptsetup.so.4 => /usr/lib/libcryptsetup.so.4 (0xf778a000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0xf777c000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0xf74b3000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xf749b000) -- /sbin/ebtables-compat libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf751e000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf74f3000) -- /sbin/fdisk libfdisk.so.1 => /usr/lib/libfdisk.so.1 (0xf7666000) -- /sbin/ip6tables-compat libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf74cb000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf74a0000) /sbin/ip6tables-compat-restore libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf7547000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf751c000) /sbin/ip6tables-compat-save libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf750b000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf74e0000) -- /sbin/iptables-compat libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf752e000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf7503000) /sbin/iptables-compat-restore libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf7530000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf7505000) /sbin/iptables-compat-save libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf74eb000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf74c0000) -- /sbin/mkhomedir_helper libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7543000) -- /sbin/mount.nfs libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7450000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7373000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf733e000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf72ba000) /sbin/mount.nfs4 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7470000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7393000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf735e000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf72da000) -- /sbin/nfbpf_compile libpcap.so.1 => /usr/lib/libpcap.so.1 (0xf767d000) /sbin/nfnl_osf libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0xf771a000) /sbin/nfsdcltrack libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xf760f000) libicui18n.so.58 => /usr/lib/libicui18n.so.58 (0xf7159000) libicuuc.so.58 => /usr/lib/libicuuc.so.58 (0xf6fad000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6 (0xf6db5000) (*) libicudata.so.58 => /usr/lib/libicudata.so.58 (0xf5497000) /sbin/nfsynproxy libpcap.so.1 => /usr/lib/libpcap.so.1 (0xf7742000) /sbin/nft libgmp.so.10 => /usr/lib/libgmp.so.10 (0xf75e1000) libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf7423000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf73f8000) -- /sbin/pam_tally2 libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74cf000) /sbin/pam_timestamp_check libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75c4000) -- /sbin/rpcbind libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf748e000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf73b2000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf737d000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf736b000) /sbin/rpcinfo libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7497000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf73ba000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7385000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7373000) /sbin/rpc.statd libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7552000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7476000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7441000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7412000) -- /sbin/runuser libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf750a000) -- /sbin/sfdisk libfdisk.so.1 => /usr/lib/libfdisk.so.1 (0xf76b7000) -- /sbin/start-stop-daemon libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7494000) -- /sbin/supervise-daemon libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf750b000) -- /sbin/umount.nfs libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf744e000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7371000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf733c000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf72b8000) /sbin/umount.nfs4 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf74d1000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf73f4000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf73bf000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf733b000) /sbin/unix_chkpwd libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf753b000) -- /sbin/veritysetup libcryptsetup.so.4 => /usr/lib/libcryptsetup.so.4 (0xf7711000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0xf7703000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0xf743a000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xf7422000) -- /sbin/xtables-compat-multi libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf7517000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf74ec000) -- /lib/libnftnl.so.4.1.0 libmxml.so.1 => /usr/lib/libmxml.so.1 (0xf7754000) libjansson.so.4 => /usr/lib/libjansson.so.4 (0xf7729000) -- /lib/libauparse.so.0.0.0 libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf752d000) -- /lib/security/pam_securetty.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf754e000) -- /lib/security/pam_namespace.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75ac000) /lib/security/pam_ftp.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7539000) /lib/security/pam_filter.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74d3000) /lib/security/pam_time.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf755c000) /lib/security/pam_warn.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf752c000) /lib/security/pam_mail.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7563000) /lib/security/pam_stress.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf751e000) /lib/security/pam_keyinit.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75b2000) /lib/security/pam_localuser.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74f3000) /lib/security/pam_limits.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7558000) /lib/security/pam_timestamp.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7540000) /lib/security/pam_succeed_if.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75be000) /lib/security/pam_issue.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf759c000) /lib/security/pam_mobile_otp.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7506000) /lib/security/pam_access.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7500000) /lib/security/pam_shells.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75b9000) /lib/security/pam_wheel.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf756e000) /lib/security/pam_env.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74cc000) /lib/security/pam_pwhistory.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf755d000) /lib/security/pam_motd.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74d4000) /lib/security/pam_rootok.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7548000) /lib/security/pam_exec.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7570000) /lib/security/pam_listfile.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7540000) /lib/security/pam_group.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75a2000) /lib/security/pam_tally.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74cd000) /lib/security/pam_mkhomedir.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf753b000) /lib/security/pam_krb5.so libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf768f000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf765a000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7487000) libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf741c000) /lib/security/pam_loginuid.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74d0000) /lib/security/pam_xauth.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf758d000) /lib/security/pam_faildelay.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf758a000) /lib/security/pam_lastlog.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75a4000) /lib/security/pam_unix.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7536000) /lib/security/pam_tally2.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7502000) /lib/security/pam_nologin.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf75aa000) /lib/security/pam_cracklib.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7554000) -- /lib/security/pam_permit.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7518000) /lib/security/pam_echo.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf756d000) /lib/security/pam_umask.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7570000) /lib/security/pam_tty_audit.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7582000) /lib/security/pam_debug.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf751b000) /lib/security/pam_rhosts.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf74da000) /lib/security/pam_yubikey.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7550000) /lib/security/pam_mktemp.so libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7510000) /lib/security/pam_userdb.so libdb-4.8.so => /usr/lib/libdb-4.8.so (0xf7609000) libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf73ca000) -- /lib/libaudit.so.1.0.0 libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf7777000) -- /lib/libpam_misc.so.0.82.1 libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf758b000) -- /lib/libpam.so.0.84.1 libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xf751e000) -- /lib/libtirpc.so.3.0.0 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf771b000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf763f000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf760a000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf742c000) ... for a total of: $ for f in /bin/* /sbin/* $( sudo find /lib/ -type f -name \*.so\* ); do echo "$f"; sudo ldd $f 2>/dev/null | grep 'usr'; done | grep -B 1 'usr' | grep ' => ' | cut -d'>' -f 2- | cut -d'(' -f 1 | sort | uniq -c | sort -nr 66 /usr/lib/libcap-ng.so.0 11 /usr/lib/libmxml.so.1 11 /usr/lib/libjansson.so.4 10 /usr/lib/libkrb5support.so.0 10 /usr/lib/libkrb5.so.3 10 /usr/lib/libk5crypto.so.3 8 /usr/lib/libgssapi_krb5.so.2 3 /usr/lib/libidn.so.11 3 /usr/lib/libfdisk.so.1 2 /usr/lib/libpopt.so.0 2 /usr/lib/libpcap.so.1 2 /usr/lib/libmagic.so.1 2 /usr/lib/libgpg-error.so.0 2 /usr/lib/libgmp.so.10 2 /usr/lib/libgcrypt.so.20 2 /usr/lib/libcryptsetup.so.4 2 /usr/lib/libcrypto.so.1.0.0 1 /usr/lib/libssl.so.1.0.0 1 /usr/lib/libsqlite3.so.0 1 /usr/lib/libslang.so.2 1 /usr/lib/libsasl2.so.3 1 /usr/lib/libnfnetlink.so.0 1 /usr/lib/liblockfile.so.1 1 /usr/lib/libldap-2.4.so.2 1 /usr/lib/liblber-2.4.so.2 1 /usr/lib/libicuuc.so.58 1 /usr/lib/libicui18n.so.58 1 /usr/lib/libicudata.so.58 1 /usr/lib/libdb-4.8.so 1 /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6 (*) .. caused by the following packages not installing to /lib*: app-crypt/mit-krb5-1.14.2 dev-db/sqlite-3.17.0 dev-libs/cyrus-sasl-2.1.26-r9 dev-libs/gmp-6.1.0 dev-libs/icu-58.2-r1 dev-libs/jansson-2.9 dev-libs/libgcrypt-1.7.8 dev-libs/libgpg-error-1.27-r1 dev-libs/mini-xml-2.10 dev-libs/openssl-1.0.2k dev-libs/popt-1.16-r2 net-dns/libidn-1.33 net-libs/liblockfile-1.09 net-libs/libnfnetlink-1.0.1 net-libs/libpcap-1.8.1 net-nds/openldap-2.4.44 sys-apps/file-5.30 sys-apps/util-linux-2.28.2 sys-devel/gcc-5.4.0-r3 (*) sys-fs/cryptsetup-1.7.4 sys-libs/db-4.8.30-r2 sys-libs/libcap-ng-0.7.8 sys-libs/slang-2.3.0 (... noting that this list is unique to this system, and so a more thorough examination is likely warranted). Here's a though - would a QA check that binaries/shared-objects installed don't link to cross-filesystem libraries on /usr be worth considering (either universally, or for separate-usr configurations only)? (*) Not this one, though - caused by /sbin/nfsdcltrack. Some binaries should just be moved from / to /usr and be done with it...
s/though/thought/
IMO we should do the /usr merge, because once we do that the differences between /{bin,sbin,lib*} and /usr/{bin,sbin,lib*) are irrelivent.
see also https://wiki.gentoo.org/wiki//usr_move
That page is incorrect however because if we follow that many things would break. You need the symlinks from /bin->/usr/bin, /lib->/usr/lib, /sbin->/usr/sbin etc.
Please note that this bug concerns the ability to maintain a fully-functional (albeit minimal) root partition capable of being used to repair a non-booting system - one where the /usr partition may be corrupt, for example. Moving everything to /usr results in a vestigial root partition which can't for used for anything useful, and a reliance on a large and fully-functional /usr partition in order for the system to start. My personal belief is that this would be a significantly sub-optimal retrograde step. In any case, in the meantime I've fixed all of the problems listed above in my overlay, documented at https://github.com/srcshelton/gentoo-ebuilds/#fixes-for-binaries-and-libraries-which-are-installed-to-the-root-filesystem-but-link-to-libraries-originally-installed-to-usr (Be warned that this overlay also does things which folks may not like or agree with - such as using the 'systemd' and 'udev' USE-flags to control whether service files and related objects or udev rules are installed, and reverts changes which caused packages to use '/run' instead of '/var/run' for cross-platform compatibility. Yeah, I'm old-skool ;) The aim, however, is to make these changes non-breaking so that any system could be switched to this overlay without breakage occurring... although that's an intention rather than a promise!)
* can't /be/ used for
Copying maintainers of affected packages. I may have missed a couple. ;)
Awesome :) The vast majority of the changes simply involve running 'gen_usr_ldscript' on the libraries which binaries or other libraries installed to the root partition link to. In my repo's ebuilds, nothing changes unless the 'sep-usr' USE-flag is active, for maximum compatibility - this may or may not fit project expectations. Some choices were needed - should libmagic be relocated to the root fs, or should nano be moved to /usr/bin? We wouldn't want people to be left without an editor, though... util-linux already relocates several libraries to the root fs - libfdisk appears to be an omission, as fdisk is quite an essential root utility. There were a couple of items - nfsdcltrack from net-fs/nfs-utils and zos-remote from sys-process/audit - which would have required relocating a large number of libraries from /usr, which is against the objective of keeping the root fs as minimal as is practical. In these cases, moving nfsdcltrack to /usr appears to be a good solution, whilst zos-remote is for a very specific use-case of having an IBM z/OS host running an SMF database accessible via a Tivoli Directory Server... given that anyone who has this setup is going to know that they need it, and that this plugin is controlled by a configure option in the upstream source in any case, making this binary available only when the 'zos' USE-flag is set seems justified (although note that this is using the flag to build a feature to interact with Z/OS, not a feature only available *on* z/OS - so this may want to be adjusted). The only other edge-case is the reliance of /bin/mail on /usr/lib/liblockfile - but since /bin/mail is actually a symlink to /usr/bin/mail, this does not appear to be an issue. Other modified ebuilds in my repo include sys-apps/coreutils and sys-apps/gawk, which relocate `uniq` and (`g`)`awk` respectively to /bin from /usr/bin, as some init scripts rely on these binaries being present (and may be invoked early-boot before localmount). Hope this helps, Stuart
Are any of the listed packages that depend on jansson "crucial to the system" or "needed for booting a basic system"?
It seems the direction of some of these moves would be for those depending on libraries in /usr to move correspondingly. If needed in early boot for e.g luks it should be part of the initramfs in any case.
They're dependencies of iptables/nftables, so I'd suggest that they're fairly placed, yes. (You may need 'net access during recovery, and so having an operational firewall does not appear unreasonable) (In reply to David Zero from comment #9) > Are any of the listed packages that depend on jansson "crucial to the > system" or "needed for booting a basic system"?
... but please bear in mind that an initramfs is not mandatory, and so the situation of booting directly from the root filesystem should also be considered. (In reply to Kristian Fiskerstrand from comment #10) > It seems the direction of some of these moves would be for those depending > on libraries in /usr to move correspondingly. If needed in early boot for > e.g luks it should be part of the initramfs in any case.
Hi, For these requires crypto features as separate USE flag, the assumption so far was that basic package can live in / while if a user enables optional USE, he should also make these libraries available at boot (initramfs or rootfs). Most of these packages also supports static USE, so that a user may have a fully functional rootfs without pulling dependencies.
(In reply to Alon Bar-Lev from comment #13) > For these requires crypto features as separate USE flag, the assumption so > far was that basic package can live in / while if a user enables optional > USE, he should also make these libraries available at boot (initramfs or > rootfs). This is interesting - presumably we don't want to put the burden on the user of having to manually relocate libraries to make optional USE flags work? I think that we likely already have this ability to only do something different with the 'sep-usr' flag I used, but this could equally well be combined with or replaced by additional logic around the optional flags (and/or `has_version` - although such an option may become a maintenance nightmare). > Most of these packages also supports static USE, so that a user may have a > fully functional rootfs without pulling dependencies. Hmm - good point, I hadn't considered static builds... but this again appears to be putting the onus upon the user to know what packages deploy to the roofs and manually set the 'static' USE flag for them (assuming that each one does offer a static build as an option?), rather than them simply having set `sep-usr` (or other flag, if preferred) if appropriate and have the right thing happen automagically? I suppose what I figured that the overall best for the majority of users would a way which makes no change by default, but allows for deployments that would benefit from relocated libraries to gain the necessary changes by the addition of a single global USE flag. (The need for the flag or other chosen mechanism could be replaced with auto-detection, but this may be fragile or lead to false positives. On the other hand, relocation could be applied unconditionally - but this seems a heavyweight response given that the majority of systems these days likely don't have a separate /usr partition in the first place!) Also note that the above list of affected packages refers only to the issues found on the (headless, server) systems I maintain - there will almost certainly be other affected packages which I don't build...
(In reply to Mike Gilbert from comment #7) > Copying maintainers of affected packages. I may have missed a couple. ;) You obviously want a tracker bug, not one huge mess of a bug that will sit for years waiting for all maintainers to un-CC.
I can't see this bug going anywhere, so marking it as WONTFIX.
