fokiintra.blogg.se

1. #WHERE TO PUT QUICKBUILD IN LINUX INSTALL#
2. #WHERE TO PUT QUICKBUILD IN LINUX FULL#
3. #WHERE TO PUT QUICKBUILD IN LINUX SOFTWARE#

Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.You can create an alias with a single character that will be equivalent to a command of your choice. Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.

#WHERE TO PUT QUICKBUILD IN LINUX SOFTWARE#

I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g: ln -s. $HOME/.local/share and $HOME/.local/bin are already used in the XDG Base Directory specification, and distributions are requested to add $HOME/.local/bin to the $PATH, so it doesn't take much to envision making a $HOME/.local/lib, etc, while you're at it. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoids cluttering your (hopefully) nice and tidy home directory! When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. For this reason, local software must not be placed outside of /usr/local without good reason. Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances).

#WHERE TO PUT QUICKBUILD IN LINUX INSTALL#

This means that an admin can install custom compiled software while still using a distro like Debian.

#WHERE TO PUT QUICKBUILD IN LINUX FULL#

The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.Īs uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. Some distributions will include $HOME/bin in your $PATH by default. Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.

Now when make & make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults. $HOME/share Local architecture-independent hierarchy.$HOME/etc Host-specific system configuration for local binaries.Using $HOME, the full local hierarchy would look like this. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME or $HOME/.local directory.

If you are the only user of a binary, installing into $HOME/bin or $HOME/.local/bin is the appropriate location since you can install it yourself and you will be the only consumer. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages. In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin.