Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
Date: Wed, 23 Nov 2022 07:38:20
1 Hello, everyone.
3 TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
4 (via USE flags) /bin/{cpio,sh,tar} symlinks.
6 Draft PR:
9 What are the problems being solved?
10 ===================================
11 We currently provide a certain degree of non-GNU userland support.
12 However, for a long time we have been more GNU-centric in some areas
13 than in other.
15 It has been an acceptable practice to replace the /bin/sh symlink to
16 point to dash for quite a while now. This eventually led me to adding
17 app-eselect/eselect-sh to streamline the support.
19 Recently we've "renamed" a bunch of common GNU tools (cpio, patch, sed,
20 tar...) to g-prefixed variants. For example, app-arch/tar now installs
21 `gtar` executable and a `tar -> gtar` symlink. The next step is actively
22 allowing people to replace the symlink with bsdcpio/bsdtar from
23 libarchive.
25 This is not only about "choice". For example, GNU cpio is a very bad
26 quality software, with practically all Linux distributions applying
27 a pile of security fixes.
30 How are they being solved?
31 ==========================
32 We add a bunch of sys-meta/* packages that serve twofold function: they
33 install symlinks for "base system tools" that point to the
34 implementation selected via USE flags, and they depend on the provider
35 via RDEPEND.
37 sys-meta/sh provides USE flags for different shells supported as /bin/sh
38 target, with bash being the default. After installing, it takes
39 ownership of /bin/sh and replaces it with the correct symlink.
41 sys-meta/cpio and sys-meta/tar install the respective tool symlinks.
42 They replace the symlinks currently installed by app-arch/cpio
43 and app-arch/tar respectively, making the replacement "relatively safe"
44 via weak blockers.
47 What are the advantages of proposed solution over eselect?
48 ==========================================================
49 1. It provides central ownership for the symlinks, and preservation of
50 the preferred variant.
52 2. It blocks you from unmerging the active implementation (via RDEPEND)
53 and leaving the symlink broken (unless all implementations are
54 explicitly eselect-aware).
56 3. It avoids writing to /bin outside package manager control (think
57 read-only rootfs that's only updated via PM).
59 4. It makes it possible to distinguish dependencies on generic tools vs.
60 specific implementation. Right now a dependency on "app-arch/tar"
61 usually triggers a "it's in @system, so remove it" response. Now "app-
62 arch/tar" will mean "I need GNU tar (i.e. I call `gtar`) specifically",
64 --
65 Best regards,
66 Michał Górny