Hello, everyone.
TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
(via USE flags) /bin/{cpio,sh,tar} symlinks.
Draft PR: https://github.com/gentoo/gentoo/pull/28390
What are the problems being solved?
===================================
We currently provide a certain degree of non-GNU userland support.
However, for a long time we have been more GNU-centric in some areas
than in other.
It has been an acceptable practice to replace the /bin/sh symlink to
point to dash for quite a while now. This eventually led me to adding
app-eselect/eselect-sh to streamline the support.
Recently we've "renamed" a bunch of common GNU tools (cpio, patch, sed,
tar...) to g-prefixed variants. For example, app-arch/tar now installs
`gtar` executable and a `tar -> gtar` symlink. The next step is actively
allowing people to replace the symlink with bsdcpio/bsdtar from
libarchive.
This is not only about "choice". For example, GNU cpio is a very bad
quality software, with practically all Linux distributions applying
a pile of security fixes.
How are they being solved?
==========================
We add a bunch of sys-meta/* packages that serve twofold function: they
install symlinks for "base system tools" that point to the
implementation selected via USE flags, and they depend on the provider
via RDEPEND.
sys-meta/sh provides USE flags for different shells supported as /bin/sh
target, with bash being the default. After installing, it takes
ownership of /bin/sh and replaces it with the correct symlink.
sys-meta/cpio and sys-meta/tar install the respective tool symlinks.
They replace the symlinks currently installed by app-arch/cpio
and app-arch/tar respectively, making the replacement "relatively safe"
via weak blockers.
What are the advantages of proposed solution over eselect?
==========================================================
1. It provides central ownership for the symlinks, and preservation of
the preferred variant.
2. It blocks you from unmerging the active implementation (via RDEPEND)
and leaving the symlink broken (unless all implementations are
explicitly eselect-aware).
3. It avoids writing to /bin outside package manager control (think
read-only rootfs that's only updated via PM).
4. It makes it possible to distinguish dependencies on generic tools vs.
specific implementation. Right now a dependency on "app-arch/tar"
usually triggers a "it's in @system, so remove it" response. Now "app-
arch/tar" will mean "I need GNU tar (i.e. I call `gtar`) specifically",
--
Best regards,
Michał Górny
