On 3/27/2021 20:32, William Hubbs wrote: > On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote: >> On 3/23/2021 07:31, Rich Freeman wrote: >>> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel <dilfri...@gentoo.org> >>> wrote: >>>> >>>>>> Council decided years ago that we don't support separate /usr without >>>>>> an initramfs, but we haven't completed that transition yet. >>>>> >>>>> Which doesn't imply that we deliberately break things. >>>> >>>> That's right. Though we should at some point start thinking about an end >>>> of support for separate usr without initramfs. >>>> >>> >>> Just to clarify - it is already unsupported at a distro level. It is >>> just that some individual packages still work with it. >>> >>> The current Council decisions on the issue are (just providing for >>> general reference): >>> >>> - "Since that particular setup may already be subtly broken today >>> depending on the installed software, Council recommends using an >>> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr >>> is on a separate partition." >>> Accepted unanimously. [1] >>> >>> - "The intention is to eventually not require maintainers to support >>> a separate /usr without an early boot mechanism once the Council >>> agrees that the necessary docs/migration path is in place." >>> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1] >>> >>> - "The Council agrees that all preparations for dropping support for >>> separate /usr without an initramfs or similar boot mechanism are >>> complete. A news item will be prepared, and users will be given one >>> month to switch after the news item has been sent." >>> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2] >>> >>> Current policy documentation: >>> Developers are not required to support using separate /usr filesystem >>> without an initramfs. [3] >>> >>> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt >>> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt >>> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 >> >> Is there a list of software/ebuilds that currently do this "subtle" handling >> of separate /usr w/o initramfs? >> >> I've got just my MIPS systems left that use a separate /usr and do not boot >> with initramfs because I build fully monolithic kernels and that makes the >> resulting vmlinux images run up against hard size limits in the SGI PROM >> (firmware, BIOS, etc) on these machines if I try to pack too large of an >> initramfs in. I can check for any software that may be switched over soon >> to a hard initramfs requirement and look at my options. > > One group of packages involved in this is any package that calls > gen_usr_ldscript. We have this function for a couple of reasons. > > Gentoo has a policy that bans *.a static libraries from being > installed in /lib*. I think this policy is unique to Gentoo, > because Most build systems I've seen do not > have separate paths for static vs dynamic libraries, so all libraries > from a package are installed in /usr/lib* or /lib*. This policy was > originally hard coded into portage some time back (I can find the commit > if you want it) before it was made a formal policy by the qa team. > It has since become a formal policy. > > Because of this policy, we have to tell upstream build systems to > install libraries in ${ED}/usr/$(get_libdir). This is fine unless you > have separate usr with no initramfs. In that case, you have binaries on > / that link to shared libraries on /usr. When we saw this happening, we > started manually moving shared libraries from /usr/lib* to /lib* if > someone needed the package at boot time. Then we hit bug 4411 [1] > where the linker was prioritizing static libraries in /usr/lib* over shared > libraries in /lib*. > > I don't know if we tried to address that upstream or not, but ultimately > gen_usr_ldscript came out of it. > > Several folks have wanted to get rid of this function for years [2]. > > I have looked into it before, and there are several things that can be done. > > We can have packages that currently build static libraries and > use gen_usr_ldscript stop building static libraries and use the > appropriate setting in their build systems to install libraries in > /$(get_libdir). This is the path OpenRC is taking per request of the qa > lead. The next release will not support the static-libs use flag. This > will actively break anyone who is expecting this use flag to exist for OpenRC. > > If a package does not build static libraries in the first place, there is > really no reason to call gen_usr_ldscript; the ebuild should be using > the upstream build system to put the libraries where they need to be.
The number of packages calling gen_usr_ldscript looks to be fairly small. Creating a TRACKER bug and sub-bugs for checking or removing the need for gen_usr_ldscript might be a way to go to pair the list down and reduce the footprint: app-accessibility/brltty sys-apps/util-linux app-arch/xz-utils sys-apps/systemd app-arch/bzip2 sys-apps/dmapi dev-libs/libiconv sys-auth/skey dev-libs/libaio sys-fs/reiserfsprogs dev-libs/libpcre2 sys-fs/zfs dev-libs/libedit sys-fs/sysfsutils dev-libs/lzo sys-fs/udev dev-libs/libusb-compat sys-fs/e2fsprogs dev-libs/libpwquality sys-fs/xfsprogs dev-libs/libintl sys-fs/reiser4progs dev-libs/libusb sys-libs/gpm dev-libs/expat sys-libs/libcap dev-libs/libpcre sys-libs/pam eclass/usr-ldscript.eclass sys-libs/ncurses eclass/toolchain-funcs.eclass sys-libs/glibc net-firewall/iptables sys-libs/pwdb net-libs/libnftnl sys-libs/cracklib net-libs/libtirpc sys-libs/libaal net-libs/libmnl sys-libs/zlib sys-apps/keyutils sys-libs/readline sys-apps/acl sys-libs/e2fsprogs-libs sys-apps/openrc sys-process/audit sys-apps/attr sys-process/procps sys-apps/tcp-wrappers > If static libraries are needed for a package that is using > gen_usr_ldscript to move shared libraries to /lib*, the only option you > have is to drop the gen_usr_ldscript call. If you do that, all of the > libraries will stay in /usr/lib*, but as soon as one package takes this > path, there will be active breakage for someone who is using a separate > /usr without an initramfs. Correct me if wrong, but static libraries are only needed during compilation, right? The *.a files are merged into the binary at link time and thus that binary can stand on its own regardless of whether the *.a files are available or not. They're not like shared libs which are needed by the loader to resolve symbols at run time. A scenario where the *.a static libs aren't available because such a /usr is unmounted, but are needed for some function, would be an anomalous system state in the first place. That would imply one was trying to do something like executing part of the system toolchain, which should be impossible in that case because the actual binaries for gcc, ld, as, and others live on /usr. We're mostly talking about the small window during boot where, on a system with /usr on a separate disk partition, /usr might not be available until some userspace tool in /bin or /sbin runs to make it available. Running the system compiler during boot would be a rare and very unique scenario (not to mention a sign of questionable development processes). > The most controversial thing to do would be the /usr merge. It would > affect far more users than the other paths for getting rid of > gen_usr_ldscript, but it would make all "separate /usr" concerns go > away along with giving us a number of other benefits. > > The short version is, anything we do to remove the gen_usr_ldscript > function will actively break some group of users. If I read the temperature right, it seems like there is desire to eliminate gen_usr_ldscript regardless of sep-usr or not. If so, then that seems the way to go. Make the eventual /usr merge a separate issue to tackle some time further down the road. > William > > [1] https://bugs.gentoo.org/4411 > [2] https://bugs.gentoo.org/417451 > -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
