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.
next prev parent 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