On 12/10/24 3:02 AM, Ionen Wolkens wrote: > 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.
It surely would -- the point of setting it for the current profile is to
make ./configure stop storing overly-specific build time paths, which
means that the resulting binpkg is now well-formed and works on both
profiles.
It is a bug when e.g. `libgcrypt-config` stores contents like this:
for i in $includes $cflags_final; do
if echo "$tmp" | /usr/bin/grep -F -v -- "$i" >/dev/null; then
But the suggested profile change would make this be:
for i in $includes $cflags_final; do
if echo "$tmp" | grep -F -v -- "$i" >/dev/null; then
And Michael is suggesting we instead encode the "API filename":
for i in $includes $cflags_final; do
if echo "$tmp" | /bin/grep -F -v -- "$i" >/dev/null; then
Since on both split and merged-usr systems, grep is always in /bin --
same as bash and sh
> (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)
tbh, /usr/share/config.site exists for this. Despite previous history of
being used for fragile caching of arbitrary configure checks that ended
up dismantled and given up as too dangerous, it remains a perfectly
suitable place for configuring impossible-to-change information such as
policy-defined paths.
> 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.
Sure, we could declare tons of things as unsupported. We could declare
split-usr as unsupported, in fact, which would feel a bit more honest
than saying "split-usr is supported, we have profiles for it, just if
you use it there are weird footguns and then your system breaks".
It's not a hard fix. It's correcting something that should be the case
regardless, even for merged-usr systems. It's quite silly for scripts to
configure the absolute path to `grep`.
> 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.
I don't see how that's supposed to help, especially given that if you
migrate your system then affected packages are defined as "affected"
based on whether they are broken and fail to work, and that remains true
during -e as well since packages depending on the broken package will
fail to successfully -e.
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
