[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: Update on the 23.0 profiles
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2024-04-08 6:40:26
Message-ID: pan$ee0f6$ad8b996e$953cd698$f59c2d04 () cox ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]