public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Orlitzky <mjo@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Update on the 23.0 profiles
Date: Sun, 07 Apr 2024 08:51:55 -0400	[thread overview]
Message-ID: <c90efee4eca8cbca4731a10392d480c1b5ba950c.camel@gentoo.org> (raw)
In-Reply-To: <114170429.nniJfEyVGO@pinacolada>

On Sun, 2024-04-07 at 14:35 +0200, Andreas K. Huettel wrote:
> 
> Uhh, I dont really remember, I think some Chinese-sounding guy asked
> me for it... (j/k) 

It is remarkably 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.



> Jokes aside, we did have bz2 in the default useflags for ages, and 
> at the time this made a lot of sense since xz/lzma and zstd were
> steadily becoming the most prevalent compression algorithms.

The flags that predate IUSE defaults can of course be forgiven.

What is improved by having these flags in every profile, vs only (say)
the desktop profiles, or in IUSE defaults?

Here's what is made worse: I can't undo it. To maintain the status quo
(I was quite happy to not have 100 packages pointlessly linked to
liblzma last week), what I want to do is set USE="-lzma -zstd". But if
I do that, then it overrides the IUSE defaults for the few packages
whose maintainers are doing the right thing, and setting IUSE="+lzma
+zstd" where it is important. For example, sys-apps/kmod, where the
defaults ensure that your system isn't made unbootable by accident.

The other option is for me to perpetually maintain a list of everything
that uses lzma/zstd inside my package.use. And to avoid the problem
above, I now have to read the ebuilds to see which ones have defaults
and which ones don't. This is also not a great way to spend my time.

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.



  reply	other threads:[~2024-04-07 12:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-06 15:06 [gentoo-dev] Update on the 23.0 profiles Andreas K. Huettel
2024-04-07  2:03 ` Michael Orlitzky
2024-04-07 12:35   ` Andreas K. Huettel
2024-04-07 12:51     ` Michael Orlitzky [this message]
2024-04-07 13:07       ` Andreas K. Huettel
2024-04-08  6:40         ` [gentoo-dev] " Duncan
2024-04-08 12:00         ` [gentoo-dev] " Michael Orlitzky
2024-04-08 15:16           ` Eddie Chapman
2024-04-07 14:48       ` Michał Górny
2024-04-07 21:09         ` Michael Orlitzky
2024-04-08  0:22           ` Alex Boag-Munroe
2024-04-08  3:07             ` Michał Górny
2024-04-07 11:35 ` Florian Schmaus
2024-04-07 12:31   ` [gentoo-dev] " Madhu
2024-04-07 13:27     ` Andreas K. Huettel
2024-04-11 16:37       ` [gentoo-dev] " Madhu
2024-04-07 12:32   ` [gentoo-dev] " Andreas K. Huettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c90efee4eca8cbca4731a10392d480c1b5ba950c.camel@gentoo.org \
    --to=mjo@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox