From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E8F6A158020 for ; Wed, 23 Nov 2022 07:38:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56BEEE0895; Wed, 23 Nov 2022 07:38:16 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 016A0E088C for ; Wed, 23 Nov 2022 07:38:15 +0000 (UTC) Message-ID: Subject: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 23 Nov 2022 08:38:11 +0100 Organization: Gentoo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 73d297ac-12e9-4968-b412-d2c4b2aaf933 X-Archives-Hash: fc95ed57f8162ff75c5d27e3313fbdc9 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? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 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? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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", --=20 Best regards, Micha=C5=82 G=C3=B3rny