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.
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.
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.
William
[1] https://bugs.gentoo.org/4411
[2] https://bugs.gentoo.org/417451
signature.asc
Description: PGP signature
