public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/4] profiles/use.desc: create USE=strip global USE flag
Date: Fri, 26 May 2023 06:06:46 +0100	[thread overview]
Message-ID: <87h6rzznlg.fsf@gentoo.org> (raw)
In-Reply-To: <20230526040219.10852-2-ionen@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]


Ionen Wolkens <ionen@gentoo.org> writes:

> Primarily intended for use by linux-mod-r1.eclass, which needs
> a global IUSE to control stripping of kernel modules *before*
> signatures and compression (alternative would be to simply never
> strip, but that seem sub-optimal).
>
> Originally meant to be USE=modules-strip or similar, but this can
> have a more general use case when portage does not know how to
> strip special files properly while the ebuild does.
>
> Notable is mingw ebuilds (wine-*, dxvk, vkd3d-proton, mingw64-*).
> If portage uses x86_64-pc-linux-strip on, e.g. mingw64-toolchain's
> runtime libraries, then at least the 32bit toolchain ends up broken
> and cannot compile anything anymore. But then dostrip -x results in
> unstripped files while we can use x86_64-w64-mingw32-strip in the
> ebuild potentially saving 60MB+. Currently this is done through
> USE=debug, but does not feel fully fitting given this isn't about
> adding debugging paths (or even symbols, or anything) and is merely
> "do not strip".
>
> No USE in ::gentoo currently contain the word "strip" and defining
> it should not conflict.

This sounds fine (and a good idea), but we may want some indication
in the USE flag description (eh), a QA policy to indicate
it's only for special situations, or some note in the devmanual.

Can see people getting this wrong and trying to use it in ebuilds
which would work otherwise. But maybe the "special" in the USE
description is enough?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

  reply	other threads:[~2023-05-26  5:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26  4:02 [gentoo-dev] [PATCH 0/4] linux-mod-r1.eclass: new eclass, rewrite of -r0 Ionen Wolkens
2023-05-26  4:02 ` [gentoo-dev] [PATCH 1/4] profiles/use.desc: create USE=strip global USE flag Ionen Wolkens
2023-05-26  5:06   ` Sam James [this message]
2023-05-26  5:25     ` Ionen Wolkens
2023-05-26  4:02 ` [gentoo-dev] [PATCH 2/4] profiles/use.desc: create USE=modules-sign " Ionen Wolkens
2023-05-26  4:02 ` [gentoo-dev] [PATCH 3/4] linux-mod-r1.eclass: new eclass, rewrite of linux-mod.eclass Ionen Wolkens
2023-05-28 12:41   ` [gentoo-dev] [PATCH v2] " Ionen Wolkens
2023-05-29 13:10     ` Ionen Wolkens
2023-05-26  4:02 ` [gentoo-dev] [PATCH 4/4] app-admin/ryzen_smu: migrate to linux-mod-r1 Ionen Wolkens

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=87h6rzznlg.fsf@gentoo.org \
    --to=sam@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