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

[Joshua Kinard]

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 <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.

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