https://bugzilla.redhat.com/show_bug.cgi?id=1421041 --- Comment #6 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- Using full paths for some specific executables is neither necessary nor sufficient. Why not sufficient? You are calling many different programs, either directly from the spec file (find, sed, install, perl, python3) or *indirectly* (e.g. %setup macro uses tar, gzip, patch). In this particular spec file there's no build, but normally when a Makefile is used, it contains references to tens of other programs (gcc, ld, ar, strip, …). So for this to be useful in any way, you'd have to make sure that *each and every one* of those programs is prefixed by path, which is of course impossible for programs called from build scripts or as helpers by macros or other programs. Instead, $PATH is set to some proper value. If somebody managed to insert rogue programs into any of the locations in $PATH, the game is over. And once $PATH is set properly, there is really no reason to use a full path to any executable in it. The reason that people use stuff like %__sed is because rpm used to provide it for some strange reason, and a cargo cult emerged. It makes no sense. (There is an exception though: %__python3 *can* be useful for example on EPEL where there is more than one python3 available, and you want to pick one of them. So sometimes %__python3 will evaluate to /usr/bin/python34 and other times to /usr/bin/python35 or whatever. But that is a different case, because we're looking for a different executable name, not ignoring $PATH. On Fedora there's just one python3, so either "python3" or "%__python3" can be used.) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
