On Tue, Dec 10, 2024 at 05:46:38AM +0000, Sam James wrote: > Michael Orlitzky <m...@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
signature.asc
Description: PGP signature
