Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to determine an appropriate directory naming structure for a package management system. The original directory structure was not POSIX-compliant in any way and certainly not UNIX-style (you'll notice it's similar to GoboLinux). The structure looked somewhat like this:

  • /Applications - applications for users (but that users have not themselves installed)
  • /System/AppResolve - application resolution (effectively /bin)
  • /System/LibResolve - library resolution (effectively /lib)
  • /System/Utilities/Applications - essential applications for system operation
  • /System/Utilities/Libraries - essential libraries for system operation

Now I need to find a way to represent this directory structure on a more UNIX-like system. AppResolve and LibResolve aren't an issue since /lib and /bin work fine for this, the issue is with the other directories.

Under each of the other directories, applications live in their own folder, so for example you might have this kind of path:


Of course, the /bin/tar symlink would resolve to this binary.

So the question is this, I need to take this kind of structure and rearrange it to fit within the UNIX-style of naming directories (particularly so that it works with the existing structure on Linux). I thought of the following, but I think it's repetitive and not very nice:

  • /usr/app/user/applications/...
  • /usr/app/system/applications/Tar/1.22/bin/tar
  • /usr/app/system/libraries/...


FOR CLARIFICATION: This isn't asking for a mapping to existing UNIX directories; it's asking for the most appropriate leading path for those "user" and "system" directories given the UNIX-naming convention (3-letter directories, etc.)

share|improve this question
So what you are asking is that you want to know the best practice for laying out your files in a way that is inconsistent with best practice according to the FHS? Is there anyone who would be able to answer this? I would be interested to see what your final solution will be. – Richard Holloway Feb 16 '12 at 9:11
The best practice for the location of the packages, consistent with UNIX-style naming of directories. It does not necessarily have to be best practise according to FHS given that if it already had an allocated area for this kind of thing, I wouldn't be asking :P. In the end, all of the files will by symlinked from their FHS standard areas into the package directories anyway. – Hach-Que Feb 17 '12 at 2:14

As suggested review man hier or other documentation on the hierarchy standards. I install packages in to /opt, which maps to your /Applications directory. On most systems I have worked with package bin directories are added into the PATH either in user's .profile or the system wide /etc/profile.

In some cases configuration and binaries may be linked into the standard bin, sbin, etc, and lib directories either in the root directory or under /usr/local.

EDIT: Reread your question. Use the standard directories bin, sbin, lib, etc, usr, and var. Source and build directories are usually be located under a location /usr/src with one directory per package. Installation is usually done by copying the files into the standard directory structure. Once installation is done it should be safe to clean or remove the directory under /usr/src.

share|improve this answer
I was originally going to go with /opt, but it feels inappropriate to put essential system packages like Glibc under there given that they aren't "optional extras". – Hach-Que Feb 16 '12 at 6:24
Essential system packages belong in the standard directories as per hier specification for your system. – BillThor Feb 17 '12 at 0:37

First of all, can you avoid the mapping issues altogether by introducing a way to compile the software in question with different configs so use real UNIX paths instead of trying to shoe-horn it?

If modifying the original in such a way that it would work re-packaged in proper locations, I would recommend using /opt as a place to stash the whole thing and sym-link too.

share|improve this answer
It's not a particular software package that requires paths such as this; the point is to use the filesystem as the package manager without deviating from Unix-style naming as much as say, GoboLinux does. – Hach-Que Feb 20 '12 at 2:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.