mupen64plus-input-raphnetraw: don't hard-code pkg-config

[orbea]

Upstream-PR: raphnet/mupen64plus-input-raphnetraw#17

Upstream hasn't been touched in 3 years and it has already pending unreviewed PRs so I thought it would be better to send it here too. I am unsure what your preferred way to merge non-upstreamed changes?

[Rosalie241]

Upstream hasn't been touched in 3 years and it has already pending unreviewed PRs so I thought it would be better to send it here too. I am unsure what your preferred way to merge non-upstreamed changes?

I usually push it in my fork(s) or in the RMG repo, but for projects which don't really get any updates, the RMG repo is fine for that.

Thank you ❤️

[eli-schwartz]

Please don't use this. "which" is less likely to be installed than "pkg-config".

"command -v" is a portable (POSIX mandated) equivalent to "which".

[Rosalie241]

mupen64plus-core also uses which there though.

[eli-schwartz]

Then mupen64plus-core, too, is wrong. :)

My attention was attracted here because @orbea implemented this change for Gentoo and I reviewed that change. I'm not directly familiar with this ecosystem though I am always happy to provide tips such as this one when I'm made aware of it.

[eli-schwartz]

Informative reading :) https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250

[Rosalie241]

Then mupen64plus-core, too, is wrong. :)

I'm not sure if I'd consider using which to be wrong per se, especially considering how widespread the usage of that command is in general.

It's just a dependency which exists, it's neither right or wrong in my opinion, and changing it for the sake of changing it is possible but I don't feel like it matters much because almost every linux system has which available or installed.

[eli-schwartz]

I have used multiple Linux distros where it wasn't available by default.

It is most commonly seen on Debian specifically because Debian has a policy guide saying that the "which" program which they privately wrote from scratch must be installed in the base system in order to be available in dpkg postinst scripts. And sure enough... Debian is trying to purge the use of "which" so they can finally drop that. :)

People often tend to code for Debian specifically. It's unfortunate. The assumption is that since Debian is the numerically largest number of Linux systems, that writing software for "Debian" is the same as writing software for "Linux".

It's just a dependency which exists, it's neither right or wrong in my opinion

That's an opinion.

I informed you of a fact, however. It is "factual* that it's wrong, and that you cannot even assume that "which" will return success when the command exists and an error when it doesn't. You can't assume it only prints stdout on success. You can't assume its results make sense for your current environment (rather than reading the rc scripts from your interactive shell). You can't assume a lot of things.

It's also quite weird to force people to install a specific dependency in order to query if an entirely different command exists on PATH, since if a user has to manually install something anyway they might as well manually install pkg-config itself. Given the shell can do this built-in... why not use the builtin?

What's the appeal of adding an additional third party dependency that is commonly not installed when the base operating system has a more reliable alternative already?

It's an incredibly simple change, anyway. 🤷

[Rosalie241]

It's an incredibly simple change, anyway. 🤷

This is only true if you don't consider having to upstream the patch for each project which RMG uses which uses that command, it's time consuming for no real gain.

But if you consider this to be a simple change, then feel free to do so for each upstream project yourself.