Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[William Hubbs]

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 <dilfridge@g.o> 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