Ionen Wolkens <io...@gentoo.org> writes: > 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.
Oh, of course... > > (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. I start to think it might be a better idea, although the transition might be a bit rough. The main problem with these bugs to begin with of course isn't the build failures when they're obvious but when they're more subtle.
