| 1 |
Hello, everyone. |
| 2 |
|
| 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. |
| 5 |
|
| 6 |
Draft PR: https://github.com/gentoo/gentoo/pull/28390 |
| 7 |
|
| 8 |
|
| 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. |
| 14 |
|
| 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. |
| 18 |
|
| 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. |
| 24 |
|
| 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. |
| 28 |
|
| 29 |
|
| 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. |
| 36 |
|
| 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. |
| 40 |
|
| 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. |
| 45 |
|
| 46 |
|
| 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. |
| 51 |
|
| 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). |
| 55 |
|
| 56 |
3. It avoids writing to /bin outside package manager control (think |
| 57 |
read-only rootfs that's only updated via PM). |
| 58 |
|
| 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", |
| 63 |
|
| 64 |
-- |
| 65 |
Best regards, |
| 66 |
Michał Górny |
Archives