3 ms·

`/usr/local` and `/opt` FTW!

ajsnigrutin 2y ago
Haven't used ubuntu/debian for years now... There used to be a "checkinstall" tool, so you'd ./configure, make, and instead of "make install" use "checkinstall" - this would make some fakeroot magic, install the package and create a deb package for it, that could be apt-get removed later. And iirc, automake uses /usr/local by default (if you didn't specify the --prefix).
- codetrotter 2y ago
  https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall Amazing! :D
jmclnx 2y ago
Yes, this is what I do: * Linux: "/usr/local" or "/opt/local" depending on distro * NetBSD: "/usr/local", NetBSD packages go into "/usr/pkg". I wish all other systems adopted pkgsrc :( * OpenBSD: "/opt/local", OpenBSD packages go into /usr/local If on a system I do not "own", like AIX at work or SDF, I use $HOME/local
- zahlman 2y ago
  I had understood that /opt is intended to be inherently "local" in the /opt/local sense. What sort of things would you put in /opt but not /opt/local?
  - jmclnx 2y ago
    /opt/local is for programs/libraries I created and smaller programs I downloaded source and compiled. /opt would be for canned items. For example, if for some reason on Linux, I want to execute the latest Firefox or Thunderbird I would get the pre-built binaries and extract them in /opt. When I did that in the past, all items will be stored in /opt/firefox and /opt/thunderbird. Plus many proprietary objects like to be sitting in /opt in their own directories.
  - paulddraper 2y ago
    Yes /opt/local is non-standard.
  - zahlman 2y ago
    (Too late to fix the typo now, but I meant "the /usr/local sense".)
    - jmclnx 2y ago
      Depends on distro OpenBSD uses it. So off to /opt NetBSD I use it for my items, no need for /opt Linux I use /opt for my items because some distros throw items there or messes around with /usr/local. Also some proporatary packages I used at work on RHEL tosses items there.
vaylian 2y ago
You need root permissions to write to these locations. For personal installations you should use $XDG_DATA_HOME: https://specifications.freedesktop.org/basedir-spec/latest/#variables https://specifications.freedesktop.org/basedir-spec/latest/#... and then create symlinks to binaries in $HOME/.local/bin.
- hnlmorg 2y ago
  “should” is massively overstating things here. For starters, it’s not a UNIX thing. It’s really more a Linux thing. Some Unixes have also adopted it but not enough for someone to argue that someone “should” be using it in reply to an article about Unix more generally. Secondly, XDG stems from managing desktop applications. Granted there’s no reason it can’t nor shouldn’t be used for CLI tools too. But equally there isn’t any reason why someone needs to use it. And on headless platforms, it makes zero sense to enforce XDG over any other Unix standard. Lastly, XDG is surprising complicated. Your example of symlinks et al demonstrates just how much additional work you’re doing just to follow XDG here. If you CLI tool doesn’t spew dozens of config files in $HOME then your recommendation isn’t any better than the one in the article. I really want to like XDG but like many things that originated from Linux, it’s far from an elegant solution to a simple problem and barely supported outside of Linux too. So I can’t blame anyone for deciding not to bother with it for their own personal software on their personal systems.
  - nmz 1y ago
    For starters, It's not really a linux thing, Xorg runs everywhere, from BSDs to even windows. Secondly, XDG is a much better standard than FHS and actually supports normal users, needing to be root to install a random application is a security vulnerability waiting to happen. Lastly XDG is not complicated at all. its around 10 envvars pointing to directories that you have to mkdir, its preferable that you put these paths in your .login as a shellscript so they're static, that's it, that's all. And its well supported, nearly everyone is moving and using $XDG_CONFIG_HOME which is $HOME/.config instead of throwing their configuration files into $HOME/.MYPROGRAM FWIW I would love if Everyone just used $HOME/.local/$FHS that way everything is reused But then again a /tmp/usr/$USER or /var/cache/usr/ should also exist, nobody cares.

Haven't used ubuntu/debian for years now... There used to be a "checkinstall" tool, so you'd ./configure, make, and instead of "make install" use "checkinstall" - this would make some fakeroot magic, install the package and create a deb package for it, that could be apt-get removed later. And iirc, automake uses /usr/local by default (if you didn't specify the --prefix).

codetrotter 2y ago
https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall Amazing! :D

jmclnx 2y ago

Yes, this is what I do: * Linux: "/usr/local" or "/opt/local" depending on distro * NetBSD: "/usr/local", NetBSD packages go into "/usr/pkg". I wish all other systems adopted pkgsrc :( * OpenBSD: "/opt/local", OpenBSD packages go into /usr/local If on a system I do not "own", like AIX at work or SDF, I use $HOME/local

zahlman 2y ago
I had understood that /opt is intended to be inherently "local" in the /opt/local sense. What sort of things would you put in /opt but not /opt/local?
- jmclnx 2y ago
  /opt/local is for programs/libraries I created and smaller programs I downloaded source and compiled. /opt would be for canned items. For example, if for some reason on Linux, I want to execute the latest Firefox or Thunderbird I would get the pre-built binaries and extract them in /opt. When I did that in the past, all items will be stored in /opt/firefox and /opt/thunderbird. Plus many proprietary objects like to be sitting in /opt in their own directories.
- paulddraper 2y ago
  Yes /opt/local is non-standard.
- zahlman 2y ago
  (Too late to fix the typo now, but I meant "the /usr/local sense".)
  - jmclnx 2y ago
    Depends on distro OpenBSD uses it. So off to /opt NetBSD I use it for my items, no need for /opt Linux I use /opt for my items because some distros throw items there or messes around with /usr/local. Also some proporatary packages I used at work on RHEL tosses items there.

vaylian 2y ago

You need root permissions to write to these locations. For personal installations you should use $XDG_DATA_HOME: https://specifications.freedesktop.org/basedir-spec/latest/#variables https://specifications.freedesktop.org/basedir-spec/latest/#... and then create symlinks to binaries in $HOME/.local/bin.

hnlmorg 2y ago
“should” is massively overstating things here. For starters, it’s not a UNIX thing. It’s really more a Linux thing. Some Unixes have also adopted it but not enough for someone to argue that someone “should” be using it in reply to an article about Unix more generally. Secondly, XDG stems from managing desktop applications. Granted there’s no reason it can’t nor shouldn’t be used for CLI tools too. But equally there isn’t any reason why someone needs to use it. And on headless platforms, it makes zero sense to enforce XDG over any other Unix standard. Lastly, XDG is surprising complicated. Your example of symlinks et al demonstrates just how much additional work you’re doing just to follow XDG here. If you CLI tool doesn’t spew dozens of config files in $HOME then your recommendation isn’t any better than the one in the article. I really want to like XDG but like many things that originated from Linux, it’s far from an elegant solution to a simple problem and barely supported outside of Linux too. So I can’t blame anyone for deciding not to bother with it for their own personal software on their personal systems.
- nmz 1y ago
  For starters, It's not really a linux thing, Xorg runs everywhere, from BSDs to even windows. Secondly, XDG is a much better standard than FHS and actually supports normal users, needing to be root to install a random application is a security vulnerability waiting to happen. Lastly XDG is not complicated at all. its around 10 envvars pointing to directories that you have to mkdir, its preferable that you put these paths in your .login as a shellscript so they're static, that's it, that's all. And its well supported, nearly everyone is moving and using $XDG_CONFIG_HOME which is $HOME/.config instead of throwing their configuration files into $HOME/.MYPROGRAM FWIW I would love if Everyone just used $HOME/.local/$FHS that way everything is reused But then again a /tmp/usr/$USER or /var/cache/usr/ should also exist, nobody cares.