random question: why does makemkv install to /usr/bin instead of /usr/local/bin?

[Raremann]

hi,

i had a random question about installing makemkv on Linux.

when following the instructions on the forum i noticed that the binary gets installed into /usr/bin/ rather than /usr/local/bin/. i thought that software compiled on your own machine is usually installed in /usr/local/bin/, to keep it separate from distribution managed packages.

So i was just kinda curious what the reasoning behind installing makemkv into /usr/bin/ instead? im kind of a noob, so maybe its really obvious, but i was just curious about it.

Thanks in advance for any clarification.

[Woodstock]

You're going to have to ask Mike about that, but... Most programs I've installed on Linux either installed in the user's own directory, or /usr/bin if they are intended for more than one user.

[tomty89]

i thought that software compiled on your own machine is usually installed in /usr/local/bin

It's not really about where it is compiled, but how it is installed.

If it is being packaged to something that would then be passed to your system package manager for installation (e.g. AUR/makepkg -> pacman on Arch), there is no "problem" for it to built to be installed to /usr(/bin,...) (Actually it is even a problem if a package ships files in /usr/local as a system package manager is not supposed to overwrite stuff in /usr/local.)

/usr/local is more or less meant for what would be installed "manually", such as `make install` run "directly" by a user, or something like that such as a simple `cp`. In other words, it is for installation method that doesn't "notify" your system package manager (but is also not flatpak or alike), so that e.g. in the worst case you can empty it and get back a "proper system" (i.e. files under /usr(/bin,...) would remain "in sync" with the "states" / information your package manager has). Conventionally it is also a way to override something in /usr/bin (e.g. a wrapper script that wraps something with the same name in /usr/bin).

I don't know what's default prefix in the `configure` script of makemkv but there's no reason that it "should be" /usr/local. Rather if e.g. you for god knows what reason decide to `make install`, you are the one who should be responsible for deciding what prefix you should / want to use.

P.S. There's also the not-so-standardized /opt, which *might* be considered "suitable" by some for what you thought /usr/local was for.

[Raremann]

hi, thanks for the explanation :>

Rather if e.g. you for god knows what reason decide to `make install`

i did run make install, because that is what it says i should do in the official installation guide on the forum. viewtopic.php?f=3&t=224

you are the one who should be responsible for deciding what prefix you should / want to use

so what would you recommend here? just leave it in /usr/bin, or reinstall to /usr/local/bin or /opt

[tomty89]

Well in reality it's generally not considered a good idea to install something by running make install yourself. These days people often use flatpak or alike if it is something your distro doesn't ship in its official repo. The more traditional way would be to look for extra repo, or something like AUR package in Arch (basically some kind of build script / "source package" that can be used to make binary package (using your distro's "build system") which would in turn be be feeded to your package manager for installation).

If you really have to make install, /usr/local is probably "the right choice". /opt AFAIK is more typically used by "official binaries" (of closed-source software), such as Spotify built by the Spotify company. (I have to admit that I don't really know the "origin" of /opt.)

[dcoke22]

https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local#11552

^ That's a good answer about /opt vs /usr/local.

[Raremann]

thanks for the help guys, i definitely learned some new stuff

i decided to install it to /usr/local in the end :>

[MrPenguin]

So i was just kinda curious what the reasoning behind installing makemkv into /usr/bin/ instead? im kind of a noob, so maybe its really obvious, but i was just curious about it.

I'll just point out that MakeMKV also installs its "VLC integration" library libmmbd.so.0 into "/usr/lib64", where libbluray can find it without any extra configuration. This wouldn't be true if MakeMKV installed it into "/usr/local/lib64" instead.

[georgesgiralt]

Well in reality it's generally not considered a good idea to install something by running make install yourself. These days people often use flatpak or alike if it is something your distro doesn't ship in its official repo. The more traditional way would be to look for extra repo, or something like AUR package in Arch (basically some kind of build script / "source package" that can be used to make binary package (using your distro's "build system") which would in turn be be feeded to your package manager for installation).

If you really have to make install, /usr/local is probably "the right choice". /opt AFAIK is more typically used by "official binaries" (of closed-source software), such as Spotify built by the Spotify company. (I have to admit that I don't really know the "origin" of /opt.)

Hi !
Disclaimer : I worked 40+ years in Unix(s)/Linux administration, so take my comments accordingly.
I would use the source code, browse it, configure it and then make it. This is done as a normal non privileged user... This way, I should avoid nasty stuff done by the configure and make commands. Some more nervous people, will then audit the binaries generated by the make command to check their non nastiness... Then, using sudo, I'll do make install. It does not bother me at all that the binaries and libs are put in "official distribution directories" as /usr or /lib. Provided you record what you've put there and remember to repeat the process every time these directories will be fully rebuild (so at every NEW install...)
On the other hand, if you use a pre-packaged app be it a .deb, flatpack or snap, you are in the hands of the packager and have to fully trust it. This is not very wise because these binaries where not checked by the distribution maker nor the original source code writer.... Even official repos can hold some malware. So compiling it yourself is, IMHO, the only way to be reasonably safe ... (bear in mid that MakeMkv contains pre-compiled binaries of which we do not know much, for good reasons)....
This is just my 2 ¢ ....

P.S.: it is good practice to have directories mounted with noexec if they should not contain binaries, nodev if they should not contain device nodes files and nosuid for everything except the directory containing the very few suid binaries your distribution uses... In order to achieve it you must have different filesystems for /usr, /var, /lib, .....

[tomty89]

Which is IMHO why a good distro should have an easy to use build system and users of the distro should learn about it. (Like with Arch one should really get to know a bit about PKGBUILD instead of blindly "pretending" that AUR is an official binary repo...)

(And I have to admit that I don't really know if other distros have something similar these days. I only heard of "PPA" but I don't know for sure about its nature.)

But to be frank, makemkv is closed-source at its core, so technically you can't "easily" tell what it might do behind the scene anyway, let alone that it's not like there hasn't been cases of open-source software being contaminated at its source.

Personally I stopped worrying too much about it, and "secure" people seem to recommend sandboxing these days. (I'm not really a user of flatpak and I don't know much about it, but I think there's some degree sandboxing...? Which seems to be one of the reasons that there are people starting to use it for at least some software.)

(Btw this seems to be getting "too Linux" even for this sub-forum...? I hope that's okay... )

---

Provided you record what you've put there

Btw don't forget that it's not really *you* putting things, but *make* as per the Makefile(s)...it might be easy to keep track of it with your 40+ years experience and/or the "scale" of makemkv, but it would be quite "something" otherwise.