From: Ionen Wolkens <ionen@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: Michael Orlitzky <mjo@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends
Date: Tue, 10 Dec 2024 03:02:31 -0500 [thread overview]
Message-ID: <Z1f1l7G1a1qd4n-r@eversor> (raw)
In-Reply-To: <87a5d4nl8h.fsf@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On Tue, Dec 10, 2024 at 05:46:38AM +0000, Sam James wrote:
> Michael Orlitzky <mjo@gentoo.org> writes:
>
> > On 2024-12-04 22:55:22, Sam James wrote:
> >> Prompted by yet another instance of this, this time at
> >> https://forums.gentoo.org/viewtopic-t-1171999.html.
> >>
> >> The results of these tests are often hardcoded into installed files
> >> which causes issues if using a binpkg of them from a merged-usr system
> >> on a non-merged-usr system. Just set the cache variables to avoid that.
> >> ...
> >> +ac_cv_path_SED="sed"
> >
> > Obviously it would defeat the purpose to put a full path in there, but
> > won't this break software that expects them to be a path (since that's
> > what the autoconf macros are documented to do)?
>
> That's a fair point and I'm not sure how to handle it. We could use
> profile.bashrc to set these?
Assume you're already aware, but still to remind that profile.bashrc
is not in PMS and ideally shouldn't rely on this for anything but
optional sanity checks or such.
Albeit I don't understand what would be doing in there, setting the
full path for the current profile wouldn't accomplish anything for
binpkg-on-different-usr-type-profile.
(on a related another note, do hope autoconf moves to being handled
like cmake/meson in the future so these things could just be in an
eclass -- we could do more complex things if needed too without
needing profile.bashrc)
That aside, I personally feel that an option could instead be
to consider merged-usr binpkg on non-merged-usr as unsupported
and only support merged-usr for binary packages.
The issue still semi-exists for users migrating their systems, but
it's at least mitigated by 23.0 suggesting emerge -e @world and thus
updating every paths.
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-12-10 8:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 22:55 [gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends Sam James
2024-12-06 0:44 ` Michael Orlitzky
2024-12-10 5:46 ` Sam James
2024-12-10 8:02 ` Ionen Wolkens [this message]
2024-12-10 8:13 ` Sam James
2024-12-10 8:26 ` Eli Schwartz
2024-12-10 8:57 ` Ionen Wolkens
2024-12-10 9:22 ` Ionen Wolkens
2024-12-10 5:54 ` Eli Schwartz
2024-12-10 18:31 ` Michael Orlitzky
2024-12-10 19:33 ` Eli Schwartz
2024-12-10 22:03 ` Michael Orlitzky
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=Z1f1l7G1a1qd4n-r@eversor \
--to=ionen@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mjo@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