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 95E53158041 for ; Mon, 8 Apr 2024 06:40:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73E16E2A5F; Mon, 8 Apr 2024 06:40:33 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3D864E2A57 for ; Mon, 8 Apr 2024 06:40:33 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rtigB-0007pa-SL for gentoo-dev@lists.gentoo.org; Mon, 08 Apr 2024 08:40:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Update on the 23.0 profiles Date: Mon, 8 Apr 2024 06:40:26 -0000 (UTC) Message-ID: References: <10606960.T7Z3S40VBb@noumea> <114170429.nniJfEyVGO@pinacolada> <5458013.Sb9uPGUboI@pinacolada> 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: Pan/0.155 (Kherson; 578af3b12) X-Archives-Salt: 6a3ab7e8-f5f7-4bc5-aada-281c36666cc6 X-Archives-Hash: 2e1917465e5ac09fa367980f6aa80ec0 Andreas K. Huettel posted on Sun, 07 Apr 2024 15:07:01 +0200 as excerpted: > Am Sonntag, 7. April 2024, 14:51:55 CEST schrieb Michael Orlitzky: [USE="lzma zstd" in 23.0 profiles] >> [R]emarkably bad timing. How it looks: Gentoo's response to the xz >> incident is to have me rebuild my entire system with everything that >> could possibly be linked to liblzma, linked to liblzma. Even on the >> hardened profiles, and with no easy way to prevent it. Agreed. Timing is ... unfortunate, making for absolutely terrible appearances. Tho for better or worse Gentoo will likely avoid the bad press Arch or the the big guys would get for such a play as we're simply not mainline enough any longer (Arch having eclipsed us as "the techie distro" in the press years ago now). > Well, we're now working with the best-audited compression library ever, > I guess. Also agreed... >> tl;dr can we turn them back off in the profile? In any scenario where >> they are beneficial, there's a better place to put them. That's the core operational debate. Perhaps better to debate zstd and lzma separately due to timing and relative ease (see below). > Easily doable with lzma, if there is consensus for it. Given lzma's easy, I'd vote for the revert, if only due to the unfortunate timing. It can always be reconsidered later, even if for pragmatic reasons "later" ends up being the /next/ profile upgrade, presumably some years away. But with the 17 downgrade to exp (if not deprecated yet), if we're changing it (and not temporarily reverting the 17 exp) it should be ASAP! > Slightly more complex for zstd since this affects gcc and binutils. > Still doable though. For zstad I'd keep as-is because it's both more difficult and lacks the direct timing issues. TLDR stop! FWIW, no effect either way here/personally, because I configured portage to ignore profile USE flags (as well as IUSE-defaults) years ago, in large part precisely /because/ of the undesired USE-flag churn. And in general it has made me a /much/ happier gentooer, because USE-flag no longer blindly toggle without my having to go unduly out of my way to find out why. (I already review the git log when a USE flag suddenly (dis)? appears, unless it's blindingly obvious why without checking the log.) The one thing I wish I had was an indication of IUSE-defaults for changes on upgrades and for new packages. Sure I can (and do) grep for IUSE if I have reason to wonder (more frequently for new packages if I don't know whether I want something enabled or not), but I imagine I miss most of the on-upgrade ISUE-default-changes as unlike the flag entirely (dis)? appearing or (un)masking (which is still active from the profile) there's nothing alerting me to IUSE-default changes. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman