I'm not sure it's worth the trouble :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2960#issuecomment-1991688117
You are receiving this because you are subscribed to this thread.
Message ID:
Oh, now I realize commit
https://github.com/rpm-software-management/rpm/commit/5ac27313a5ecd601e01393cda10e6f16728a434a
was *before*
https://github.com/rpm-software-management/rpm/commit/bbb289e303d8c72b9e35410e593b8d92b006bec1
so I guess that's the explanation :smile:
I'll hack up a fixup
And while at it, `find-debuginfo` should be handled the same way as `awk` here.
@pmatilai, I wonder what the rationale of commit
https://github.com/rpm-software-management/rpm/commit/5ac27313a5ecd601e01393cda10e6f16728a434a
was? Besides `macros.in`, we're only using it in `atlocal.in` but that
Yep, I was originally going with exactly that (even had the code locally) but
then I realized there was no point in not just using `find_program()` :smile:
The reason we have `findutil()` is so that we have a sanitized path selection
(i.e. not `$PATH`) for these utilities that go into
Merged #2960 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2960#event-12089020248
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh, I was thinking of passing a new arg to findutil() instead, but I see
there's already a similar precedent from find-debuginfo. That's just as well
then.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2960#issuecomment-1991616494
You
