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 (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A5FAB158232 for ; Tue, 10 Dec 2024 09:22:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B926AE0BD3; Tue, 10 Dec 2024 09:22:44 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 06E27E0BAA for ; Tue, 10 Dec 2024 09:22:43 +0000 (UTC) Date: Tue, 10 Dec 2024 04:22:40 -0500 From: Ionen Wolkens To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <4bfc3e7b67c2a1398c8efa9700b66fe9ac0f2736.1733352922.git.sam@gentoo.org> <87a5d4nl8h.fsf@gentoo.org> 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BCO++eIN3ACuskwP" Content-Disposition: inline In-Reply-To: X-Archives-Salt: c66c1827-0ef1-436b-9791-82326744ff4d X-Archives-Hash: 4e97b7d62e23f63877fd27c49de26cba --BCO++eIN3ACuskwP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2024 at 03:26:38AM -0500, Eli Schwartz wrote: > On 12/10/24 3:02 AM, Ionen Wolkens wrote: > > That aside, I personally feel that an option could instead be > > to consider merged-usr binpkg on non-merged-usr as unsupported > > and only support merged-usr for binary packages. >=20 >=20 > Sure, we could declare tons of things as unsupported. We could declare > split-usr as unsupported, in fact, which would feel a bit more honest > than saying "split-usr is supported, we have profiles for it, just if > you use it there are weird footguns and then your system breaks". No need to take it to extremes, binpkgs aren't everything and there's no need to drop support for something just because the binpkgs don't support it. I think it's fair if binpkgs only support the primary configurations, much like how they use default profile USEs given supporting all USE configurations is virtually impossible. Ideally it'd be nice if binpkgs could make the distinction between profiles they are compatible with or not so it wouldn't be a "footgun". Also an issue for non-binpkg where users switch to profiles that need migration without doing the migration (at best we've been trying to stop them with profile.bashrc or ebuild checks). Aka, distinction between profiles that do or need something special vs profiles that just change a few USE/masks isn't clear cut. > > The issue still semi-exists for users migrating their systems, but > > it's at least mitigated by 23.0 suggesting emerge -e @world and thus > > updating every paths. >=20 >=20 > I don't see how that's supposed to help, especially given that if you > migrate your system then affected packages are defined as "affected" > based on whether they are broken and fail to work, and that remains true > during -e as well since packages depending on the broken package will > fail to successfully -e. I said semi-affected given there's a compat symlink that keeps things working, the paths are just kind of technically wrong but works. It would be an issue for merged-usr -> non-merged-usr switch, but we don't have a migration path nor tools for the other way around so users always been a bit on their own there. --=20 ionen --BCO++eIN3ACuskwP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmdYCGAACgkQskQGsLCs QzRtSQgAk4yaKtAN9as+xuLlUzFHdKr+2n2np2edrmGef/88zrjNMQNoILcKUwG/ +dE2eLZjsMO88MkZvO3UBE5wE3zWv2UFpJVJy9lUmTuXD2qk8Llu7NfDNM1oLgJW zKDCgPi8gDjMZPo9EdzLhk/5s6VkR4KnkNdGF8qnTfTafmirs6fSPbdoCjR9xavh ghsJc2UALNqcWVy/g040KkU1BlPGFaCDvxTeTszT/XLKyuyMjQE9b5YUzZ79zfjP 3ictjKeGr2rEORiDLj3NHMG8xZ0TzQ+RRYYSh0Hi3OHbHcI9OhHclw1Au8/GZmkU L6j1km0xmr+508rA4zIxKdHjjwfp0g== =h08J -----END PGP SIGNATURE----- --BCO++eIN3ACuskwP--