10

When installing software compiled from source, I normally place them in /usr/local/, which is by far the most common default in my experience, and standard practice at least on Debian and its derivatives.

Now I want to install something in my home directory, and while I could in theory create any subdirectory and place it there, I started wondering about the different options, and if there is a standard practice. I've found essentially two answers:

  • Custom subdirectory, named something like Programs, usr
  • No subdirectory, having subdirectories ~/bin, ~/lib64

I don't like either of these, and thought that since there is already a ~/.local subdirectory, why not install there? It already contains a ~/.local/share, which has come to mean a local user's private /usr/share, so it would seem very logical to install programs, creating the whole ~/.local/bin, ~/.local/lib etc.

My question is: Is it ok to install local software in ~/.local?

Why don't I find any references to this when I search google or stackexchange for places to install per-user software? To me it seems like such an obvious location that the lack of posts suggesting it means there must be a catch somewhere.

Perhaps someone who has done this can share their experience, be it positive or negative?

Community
  • 1
pipe
  • 920
  • I couldn't find any reference to ~/.local in the FHS -- just /usr/local, (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY) – Jeff Schaller Jan 30 '16 at 13:16
  • @JeffSchaller You're right, I've changed the tag to XDG. – pipe Jan 30 '16 at 15:19
  • 1
    Be careful that ~/.local/share is used for per-user application data. Why not create a ~/.usr and install things there! – cylgalad Jan 31 '16 at 08:53

4 Answers4

4

It's fine.

Remember, it's your home directory; you can do anything you want in there. GNOME/KDE/whatever might complain if you go around deleting .config, but anything you do in your home directory will, by definition, only affect you. Adding some directories in .local is harmless.

Putting something in a dot directory will be mildly inconvenient, depending on your workflow. How much it will affect you depends on how you navigate the filesystem and how often you'll need to do it. If it was me, I'd make a regular directory to act as a root (probably call it local or apps) and use it that way, but that's personal preference.

Where you'll run into problems is that the system isn't set up to see your directory. You'll need to adjust PATH, MANPATH, INFOPATH, and LD_LIBRARY_PATH in your .bashrc (or whatever is appropriate for your shell). There will likely be other small "gotchas" as well.

I'm willing to be that there aren't many posts here about it because not many people need to do it. If it's a personal machine, there are few reasons not to use /usr/local. Everything's already set up for it in most distributions. If you're just installing a few apps, a lot of people make directories in /opt (like /opt/blender). Solaris does this when you install a package.

The only real use case for what you're describing is for developers or people who don't have root on their machine. Most people who don't have root just ask the admin to install a program for them - they probably wouldn't know how to compile a program anyway.

Jeff Spaulding
  • 684
  • "The only real use case for what you're describing is for developers", bingo. I pull this program from the git repository many times per day, and installing it in my home means that I can more easily automate the upgrade without having to set up special sudo rights or similar. I think I'll simply try this out. – pipe Jan 31 '16 at 02:34
  • 1
    "because not many people need to do it" -- nah, it's extremely common on clusters. It's puzzling that, after decades, Linux still doesn't have an established standard convention for doing this. – Konrad Rudolph Jul 28 '22 at 07:27
  • Not really. You say decades, but regular users having accounts on clusters wasn't a common thing even one decade ago. There should probably be some kind of convention for this, but there's security issues involved and that always complicates matters. Honestly, I expect we'll find people using containerized user accounts as a common thing before we see a common convention on home directory software trees. I miss the simple days when you'd just pester your sysadmin to upgrade Perl. – Jeff Spaulding Jul 30 '22 at 05:32
  • @JeffSpaulding I can assure you that it was common in my field (scientific computing, more specifically genomics). What security issues are you imagining that are not adequately addressed by existing POSIX file permissions? – Konrad Rudolph Aug 03 '22 at 12:55
  • It's the lack of POSIX permissions that is (part of) the problem. If you're compiling your own software (or worse, downloading executable code) in your home directory, then your user is the file owner. There's much more to it than that, though, such as library and $PATH order. I'd recommend discussing the topic with a UNIX security expert if you're curious. – Jeff Spaulding Aug 05 '22 at 07:02
  • @JeffSpaulding Sorry, I didn't see the comment since you didn't @ me. Anyway, I still don't understand your potential security concerns. I am decently familiar with POSIX security (no expert, but vastly more knowledgeable than most Linux users due to my past jobs), and I still don't understand what you're alluding to. What's more, I don't know any sysadmins who would share your concern. Could you describe (or link to) a concrete security risk which this would cause, and which isn't always present during conventional user interaction with a computer? – Konrad Rudolph Aug 19 '22 at 10:41
  • @konrad-rudolph When I recommended discussing the topic with a UNIX security expert, I didn't mean me. I'm just some guy that's been using this stuff forever. Why not make a post in the UNIX/Linux StackExchange asking about the security ramifications of running your own software prefix tree in your home directory? They'd be able to give you a better explanation than I would. – Jeff Spaulding Aug 25 '22 at 10:09
  • @JeffSpaulding My previous comment was a gentle nudge to say that I think you’re wrong about this: there’s no security risk here (above and beyond what exists any time you run any third-party software — in particular, nothing relating to the three points you mentioned: user permissions/ownership, PATH order and libraries). I was hoping that, by trying (and failing) to come up with a concrete scenario, you’d understand this. – Konrad Rudolph Aug 25 '22 at 10:12
  • @konrad-rudolph Yeah, I got that. And I don't think I'm wrong, which should be obvious by my response. I have multiple concrete examples in my head. But the comments aren't an appropriate form for an essay, which is what a well-researched answer would be. Plus I'm not a UNIX security expert, so I have only the credibility of a long-term UNIX user. Hence my suggestion that you ask on the U/L Stackexchange and get the long-form answers you want. Or you're welcome to disagree and move on. – Jeff Spaulding Aug 26 '22 at 03:58
2

The common convention (used e.g. with some install-home targets, like for mercurial, known as hg) is to put them directly under $HOME, i.e., in $HOME/bin, $HOME/etc, $HOME/lib, and so on. This is the result of the GNUish configuration dance starting with ./configure --prefix=$HOME.

vonbrand
  • 18,253
1

The obvious reasons why not:

  • user's home-directories are often limited in size (quotas on shared systems)
  • predefined profiles often have already added ~/bin to your PATH (making it more convenient to install in that directory)
  • if you have control of the machine, installing into a shareable location works out nicely, e.g., /usr/local/bin. Your dot-directory is not (usually) shareable with other user accounts.
  • it's easier to overlook dot-directories when looking for abnormal disk-space usage. For example, the ccache mis-feature used 1Gb in my home, before I noticed it. Browsers and desktop junk are also frequent offenders (and more than 15 years into the process none deliver a suitable disk-management tool).

On the positive side: it would reduce clutter — a little. I have 55 regular directories in my home directory, as well as 91 dot-directories.

Thomas Dickey
  • 76,765
-2

Yes you can but it will get polluted by other software installs. I use $HOME/local and modify bashrc with path like

export PATH=.:${HOME}/local/bin:${PATH}

export LD_LIBRARY_PATH=${HOME}/local/lib:${LD_LIBRARY_PATH}

export PREFIX=${HOME}/local

so you know what you've installed and since they are first on the path stack they will be found before the other binaries, libs, etc. When using things like configure or cmake, the prefix is easy to remember

--prefix=${PREFIX}
Skynet
  • 1
  • 1
    (1) It’s OK to put software in ~/.local, “but it will get polluted by other software installs.”  So “I use $HOME/local …” (instead).  Huh?  What’s the difference? (2) Don’t put . at the beginning of PATH. – Scott - Слава Україні Jan 14 '20 at 20:38
  • (1) software install config and other files into .local NONE will install into local by default (2) I always use .: in my path – Skynet Jan 21 '20 at 09:27