Into which directory should I install programs in Linux?
I want to install a program in Linux and run it as a daemon. (Team Speak 3 in this case, but the question is general in nature). There is no package provided, only tarred binaries.
Where in directory structure should I put such a program by convention?
On the web I found that /opt is for "optional addon apps", while /usr is for "user programs".
I found one tutorial suggesting /opt while the other sugested /usr.
So which one is "more correct"?
software-installation directory-structure
add a comment |
I want to install a program in Linux and run it as a daemon. (Team Speak 3 in this case, but the question is general in nature). There is no package provided, only tarred binaries.
Where in directory structure should I put such a program by convention?
On the web I found that /opt is for "optional addon apps", while /usr is for "user programs".
I found one tutorial suggesting /opt while the other sugested /usr.
So which one is "more correct"?
software-installation directory-structure
1
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often/usr/local
) OR on how to create your own package for it.
– Leiaz
Apr 29 '14 at 11:31
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41
add a comment |
I want to install a program in Linux and run it as a daemon. (Team Speak 3 in this case, but the question is general in nature). There is no package provided, only tarred binaries.
Where in directory structure should I put such a program by convention?
On the web I found that /opt is for "optional addon apps", while /usr is for "user programs".
I found one tutorial suggesting /opt while the other sugested /usr.
So which one is "more correct"?
software-installation directory-structure
I want to install a program in Linux and run it as a daemon. (Team Speak 3 in this case, but the question is general in nature). There is no package provided, only tarred binaries.
Where in directory structure should I put such a program by convention?
On the web I found that /opt is for "optional addon apps", while /usr is for "user programs".
I found one tutorial suggesting /opt while the other sugested /usr.
So which one is "more correct"?
software-installation directory-structure
software-installation directory-structure
edited Apr 29 '14 at 23:18
Gilles
537k12810881605
537k12810881605
asked Apr 29 '14 at 11:09
EiverEiver
265139
265139
1
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often/usr/local
) OR on how to create your own package for it.
– Leiaz
Apr 29 '14 at 11:31
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41
add a comment |
1
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often/usr/local
) OR on how to create your own package for it.
– Leiaz
Apr 29 '14 at 11:31
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41
1
1
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often
/usr/local
) OR on how to create your own package for it.– Leiaz
Apr 29 '14 at 11:31
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often
/usr/local
) OR on how to create your own package for it.– Leiaz
Apr 29 '14 at 11:31
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41
add a comment |
6 Answers
6
active
oldest
votes
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local
) OR on how to create your own package for it.
As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/
is probably best.
(But, for instance, in Archlinux, the package manager can install there, so I'd still make a PKGBUILD to install in /opt
.)
Also distributions usually try to follow the Filesystem Hierarchy Standard, so this is where to look for more generic convention.
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
add a comment |
The Linux Standard Base and the Filesystem Hierarchy Standard are arguably the standards of where and how you should install software on a Linux system and would suggest placing software that isn't included in your distribution either in /opt
or /usr/local/
or rather subdirectories therein (/opt/<package> /opt/<provider> /usr/local/bin
).
Best practice is to convert software you download to a installable software package native to your distribution, for instance dpkg or rpm formats. That will facilitate reporting, upgrading and cleanly removing the software.
This pretty much just re-states the question rather than answering it. The OP was aware that/opt
and/usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).
– JBentley
2 days ago
add a comment |
If you will be compiling your own software then you ultimately control the installation location. By convention, software compiled and installed manually (not through a package manager, e.g apt, yum, pacman) is installed in /usr/local
. Some packages (programs) will create a sub-directory within /usr/local
to store all of their relevant files in, such as /usr/local/openssl
. Other packages will install their necessary files into existing directories such as /usr/local/sbin
and /usr/local/etc
. These are simply default locations and can be changed during compilation.
When you are compiling software, the installation location can be specified by using the --prefix=
option when running ./configure
. It is highly recommended that you look at all of the available options for your package by running $ ./configure --help | less
. Additionally, browsing the INSTALL and README documents provided with your package is a good idea. They tend to include installation instructions and dependency information that is specific to the package.
It should also be noted that although you can store software anywhere, according to the FHS, source code for locally installed software should be stored in /usr/local/src
Standardizing where you store your source trees will allow you to easily locate a tree if you need to copy a stock configuration file or binary. Even though some packages use it, your source code should not be stored in /usr/src
as that is designated for system software such as the kernel.
Finally, you need to ensure that your installation location is included in your $PATH
. If you decide to install your package in /opt
but it's not in your $PATH
your shell won't find the executables and you will have to use the absolute path to invoke your programs. Here are some great discussions from AU about configuring your $PATH
Additional reading: man hier
add a comment |
Binaries go in the bin
folder by common conventions, how you would organize your package structure is up to you, I can think of /opt/<prog_name>/
if it is just a list of binaries.
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
add a comment |
I had the same question while installing Eclipse via the Eclipse installer.
I noticed that Gimp, Perl and Vim are installed in the /usr/share
folder and decided to install it there.
add a comment |
There are two ways programs can be installed, depending on how they are packed.
Via the software manager (apt, synaptic, Gdebi etc.) – the program is in a form of package, usually .deb or rpm. Software managers in most cases handles dependencies and will install binaries usually into
/usr/bin
, config files into/etc
and so on. They may also create a config file for the program in your home, usually~/.foo
. If you can edit this file, you can also easily change settings for your session this way. When you remove the package, the manager will find all the files and cleanly remove them (it stored all the locations in a special text file). But it may preserve some config files, for example the one in your home folder.You download a program (usually compressed) in a form of pre-compiled binary files for your architecture. The executable file of the program is usually in a single folder next to other files (dynamically linked libraries etc.) This whole folder can be copied, with root privileges, either to
/opt
or/usr/bin
and could, if permissions allow, be used by any user. I myself put the folders with binary files into my home folder to~/bin
. Now you should be able to run the program by invoking its bin file.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f127076%2finto-which-directory-should-i-install-programs-in-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local
) OR on how to create your own package for it.
As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/
is probably best.
(But, for instance, in Archlinux, the package manager can install there, so I'd still make a PKGBUILD to install in /opt
.)
Also distributions usually try to follow the Filesystem Hierarchy Standard, so this is where to look for more generic convention.
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
add a comment |
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local
) OR on how to create your own package for it.
As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/
is probably best.
(But, for instance, in Archlinux, the package manager can install there, so I'd still make a PKGBUILD to install in /opt
.)
Also distributions usually try to follow the Filesystem Hierarchy Standard, so this is where to look for more generic convention.
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
add a comment |
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local
) OR on how to create your own package for it.
As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/
is probably best.
(But, for instance, in Archlinux, the package manager can install there, so I'd still make a PKGBUILD to install in /opt
.)
Also distributions usually try to follow the Filesystem Hierarchy Standard, so this is where to look for more generic convention.
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local
) OR on how to create your own package for it.
As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/
is probably best.
(But, for instance, in Archlinux, the package manager can install there, so I'd still make a PKGBUILD to install in /opt
.)
Also distributions usually try to follow the Filesystem Hierarchy Standard, so this is where to look for more generic convention.
edited Apr 29 '14 at 12:11
answered Apr 29 '14 at 11:55
LeiazLeiaz
2,4341614
2,4341614
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
add a comment |
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
is there some alias to know where are located each directory by usage? (for example, where to put root configurations, where to put binaries, dependencies, templates...)
– Sandburg
Feb 5 at 11:09
add a comment |
The Linux Standard Base and the Filesystem Hierarchy Standard are arguably the standards of where and how you should install software on a Linux system and would suggest placing software that isn't included in your distribution either in /opt
or /usr/local/
or rather subdirectories therein (/opt/<package> /opt/<provider> /usr/local/bin
).
Best practice is to convert software you download to a installable software package native to your distribution, for instance dpkg or rpm formats. That will facilitate reporting, upgrading and cleanly removing the software.
This pretty much just re-states the question rather than answering it. The OP was aware that/opt
and/usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).
– JBentley
2 days ago
add a comment |
The Linux Standard Base and the Filesystem Hierarchy Standard are arguably the standards of where and how you should install software on a Linux system and would suggest placing software that isn't included in your distribution either in /opt
or /usr/local/
or rather subdirectories therein (/opt/<package> /opt/<provider> /usr/local/bin
).
Best practice is to convert software you download to a installable software package native to your distribution, for instance dpkg or rpm formats. That will facilitate reporting, upgrading and cleanly removing the software.
This pretty much just re-states the question rather than answering it. The OP was aware that/opt
and/usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).
– JBentley
2 days ago
add a comment |
The Linux Standard Base and the Filesystem Hierarchy Standard are arguably the standards of where and how you should install software on a Linux system and would suggest placing software that isn't included in your distribution either in /opt
or /usr/local/
or rather subdirectories therein (/opt/<package> /opt/<provider> /usr/local/bin
).
Best practice is to convert software you download to a installable software package native to your distribution, for instance dpkg or rpm formats. That will facilitate reporting, upgrading and cleanly removing the software.
The Linux Standard Base and the Filesystem Hierarchy Standard are arguably the standards of where and how you should install software on a Linux system and would suggest placing software that isn't included in your distribution either in /opt
or /usr/local/
or rather subdirectories therein (/opt/<package> /opt/<provider> /usr/local/bin
).
Best practice is to convert software you download to a installable software package native to your distribution, for instance dpkg or rpm formats. That will facilitate reporting, upgrading and cleanly removing the software.
edited Apr 29 '14 at 23:39
Faheem Mitha
23k1881136
23k1881136
answered Apr 29 '14 at 12:13
HBruijnHBruijn
5,5861525
5,5861525
This pretty much just re-states the question rather than answering it. The OP was aware that/opt
and/usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).
– JBentley
2 days ago
add a comment |
This pretty much just re-states the question rather than answering it. The OP was aware that/opt
and/usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).
– JBentley
2 days ago
This pretty much just re-states the question rather than answering it. The OP was aware that
/opt
and /usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).– JBentley
2 days ago
This pretty much just re-states the question rather than answering it. The OP was aware that
/opt
and /usr/local/
were the two available options but wanted specific information on which one of those options to use. This could be a valid answer if it instead made a claim that the two locations are interchangeable (although I would dispute that it would be a correct answer in such case).– JBentley
2 days ago
add a comment |
If you will be compiling your own software then you ultimately control the installation location. By convention, software compiled and installed manually (not through a package manager, e.g apt, yum, pacman) is installed in /usr/local
. Some packages (programs) will create a sub-directory within /usr/local
to store all of their relevant files in, such as /usr/local/openssl
. Other packages will install their necessary files into existing directories such as /usr/local/sbin
and /usr/local/etc
. These are simply default locations and can be changed during compilation.
When you are compiling software, the installation location can be specified by using the --prefix=
option when running ./configure
. It is highly recommended that you look at all of the available options for your package by running $ ./configure --help | less
. Additionally, browsing the INSTALL and README documents provided with your package is a good idea. They tend to include installation instructions and dependency information that is specific to the package.
It should also be noted that although you can store software anywhere, according to the FHS, source code for locally installed software should be stored in /usr/local/src
Standardizing where you store your source trees will allow you to easily locate a tree if you need to copy a stock configuration file or binary. Even though some packages use it, your source code should not be stored in /usr/src
as that is designated for system software such as the kernel.
Finally, you need to ensure that your installation location is included in your $PATH
. If you decide to install your package in /opt
but it's not in your $PATH
your shell won't find the executables and you will have to use the absolute path to invoke your programs. Here are some great discussions from AU about configuring your $PATH
Additional reading: man hier
add a comment |
If you will be compiling your own software then you ultimately control the installation location. By convention, software compiled and installed manually (not through a package manager, e.g apt, yum, pacman) is installed in /usr/local
. Some packages (programs) will create a sub-directory within /usr/local
to store all of their relevant files in, such as /usr/local/openssl
. Other packages will install their necessary files into existing directories such as /usr/local/sbin
and /usr/local/etc
. These are simply default locations and can be changed during compilation.
When you are compiling software, the installation location can be specified by using the --prefix=
option when running ./configure
. It is highly recommended that you look at all of the available options for your package by running $ ./configure --help | less
. Additionally, browsing the INSTALL and README documents provided with your package is a good idea. They tend to include installation instructions and dependency information that is specific to the package.
It should also be noted that although you can store software anywhere, according to the FHS, source code for locally installed software should be stored in /usr/local/src
Standardizing where you store your source trees will allow you to easily locate a tree if you need to copy a stock configuration file or binary. Even though some packages use it, your source code should not be stored in /usr/src
as that is designated for system software such as the kernel.
Finally, you need to ensure that your installation location is included in your $PATH
. If you decide to install your package in /opt
but it's not in your $PATH
your shell won't find the executables and you will have to use the absolute path to invoke your programs. Here are some great discussions from AU about configuring your $PATH
Additional reading: man hier
add a comment |
If you will be compiling your own software then you ultimately control the installation location. By convention, software compiled and installed manually (not through a package manager, e.g apt, yum, pacman) is installed in /usr/local
. Some packages (programs) will create a sub-directory within /usr/local
to store all of their relevant files in, such as /usr/local/openssl
. Other packages will install their necessary files into existing directories such as /usr/local/sbin
and /usr/local/etc
. These are simply default locations and can be changed during compilation.
When you are compiling software, the installation location can be specified by using the --prefix=
option when running ./configure
. It is highly recommended that you look at all of the available options for your package by running $ ./configure --help | less
. Additionally, browsing the INSTALL and README documents provided with your package is a good idea. They tend to include installation instructions and dependency information that is specific to the package.
It should also be noted that although you can store software anywhere, according to the FHS, source code for locally installed software should be stored in /usr/local/src
Standardizing where you store your source trees will allow you to easily locate a tree if you need to copy a stock configuration file or binary. Even though some packages use it, your source code should not be stored in /usr/src
as that is designated for system software such as the kernel.
Finally, you need to ensure that your installation location is included in your $PATH
. If you decide to install your package in /opt
but it's not in your $PATH
your shell won't find the executables and you will have to use the absolute path to invoke your programs. Here are some great discussions from AU about configuring your $PATH
Additional reading: man hier
If you will be compiling your own software then you ultimately control the installation location. By convention, software compiled and installed manually (not through a package manager, e.g apt, yum, pacman) is installed in /usr/local
. Some packages (programs) will create a sub-directory within /usr/local
to store all of their relevant files in, such as /usr/local/openssl
. Other packages will install their necessary files into existing directories such as /usr/local/sbin
and /usr/local/etc
. These are simply default locations and can be changed during compilation.
When you are compiling software, the installation location can be specified by using the --prefix=
option when running ./configure
. It is highly recommended that you look at all of the available options for your package by running $ ./configure --help | less
. Additionally, browsing the INSTALL and README documents provided with your package is a good idea. They tend to include installation instructions and dependency information that is specific to the package.
It should also be noted that although you can store software anywhere, according to the FHS, source code for locally installed software should be stored in /usr/local/src
Standardizing where you store your source trees will allow you to easily locate a tree if you need to copy a stock configuration file or binary. Even though some packages use it, your source code should not be stored in /usr/src
as that is designated for system software such as the kernel.
Finally, you need to ensure that your installation location is included in your $PATH
. If you decide to install your package in /opt
but it's not in your $PATH
your shell won't find the executables and you will have to use the absolute path to invoke your programs. Here are some great discussions from AU about configuring your $PATH
Additional reading: man hier
edited Apr 13 '17 at 12:22
Community♦
1
1
answered Apr 29 '14 at 14:49
CreekCreek
3,74611229
3,74611229
add a comment |
add a comment |
Binaries go in the bin
folder by common conventions, how you would organize your package structure is up to you, I can think of /opt/<prog_name>/
if it is just a list of binaries.
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
add a comment |
Binaries go in the bin
folder by common conventions, how you would organize your package structure is up to you, I can think of /opt/<prog_name>/
if it is just a list of binaries.
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
add a comment |
Binaries go in the bin
folder by common conventions, how you would organize your package structure is up to you, I can think of /opt/<prog_name>/
if it is just a list of binaries.
Binaries go in the bin
folder by common conventions, how you would organize your package structure is up to you, I can think of /opt/<prog_name>/
if it is just a list of binaries.
edited Apr 29 '14 at 12:12
Raphael Ahrens
7,02152846
7,02152846
answered Apr 29 '14 at 11:14
bbsanembbsanem
112
112
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
add a comment |
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
I am afraid that Team Speak 3 guys made the program in such a way that everything it needs sits just in one folder (binaries,config files, logs), so It doesn't use /bin or /etc or /var/log
– Eiver
Apr 29 '14 at 11:36
add a comment |
I had the same question while installing Eclipse via the Eclipse installer.
I noticed that Gimp, Perl and Vim are installed in the /usr/share
folder and decided to install it there.
add a comment |
I had the same question while installing Eclipse via the Eclipse installer.
I noticed that Gimp, Perl and Vim are installed in the /usr/share
folder and decided to install it there.
add a comment |
I had the same question while installing Eclipse via the Eclipse installer.
I noticed that Gimp, Perl and Vim are installed in the /usr/share
folder and decided to install it there.
I had the same question while installing Eclipse via the Eclipse installer.
I noticed that Gimp, Perl and Vim are installed in the /usr/share
folder and decided to install it there.
edited Feb 5 at 11:56
Sandburg
8710
8710
answered Apr 3 '16 at 17:58
senpaisenpai
111
111
add a comment |
add a comment |
There are two ways programs can be installed, depending on how they are packed.
Via the software manager (apt, synaptic, Gdebi etc.) – the program is in a form of package, usually .deb or rpm. Software managers in most cases handles dependencies and will install binaries usually into
/usr/bin
, config files into/etc
and so on. They may also create a config file for the program in your home, usually~/.foo
. If you can edit this file, you can also easily change settings for your session this way. When you remove the package, the manager will find all the files and cleanly remove them (it stored all the locations in a special text file). But it may preserve some config files, for example the one in your home folder.You download a program (usually compressed) in a form of pre-compiled binary files for your architecture. The executable file of the program is usually in a single folder next to other files (dynamically linked libraries etc.) This whole folder can be copied, with root privileges, either to
/opt
or/usr/bin
and could, if permissions allow, be used by any user. I myself put the folders with binary files into my home folder to~/bin
. Now you should be able to run the program by invoking its bin file.
add a comment |
There are two ways programs can be installed, depending on how they are packed.
Via the software manager (apt, synaptic, Gdebi etc.) – the program is in a form of package, usually .deb or rpm. Software managers in most cases handles dependencies and will install binaries usually into
/usr/bin
, config files into/etc
and so on. They may also create a config file for the program in your home, usually~/.foo
. If you can edit this file, you can also easily change settings for your session this way. When you remove the package, the manager will find all the files and cleanly remove them (it stored all the locations in a special text file). But it may preserve some config files, for example the one in your home folder.You download a program (usually compressed) in a form of pre-compiled binary files for your architecture. The executable file of the program is usually in a single folder next to other files (dynamically linked libraries etc.) This whole folder can be copied, with root privileges, either to
/opt
or/usr/bin
and could, if permissions allow, be used by any user. I myself put the folders with binary files into my home folder to~/bin
. Now you should be able to run the program by invoking its bin file.
add a comment |
There are two ways programs can be installed, depending on how they are packed.
Via the software manager (apt, synaptic, Gdebi etc.) – the program is in a form of package, usually .deb or rpm. Software managers in most cases handles dependencies and will install binaries usually into
/usr/bin
, config files into/etc
and so on. They may also create a config file for the program in your home, usually~/.foo
. If you can edit this file, you can also easily change settings for your session this way. When you remove the package, the manager will find all the files and cleanly remove them (it stored all the locations in a special text file). But it may preserve some config files, for example the one in your home folder.You download a program (usually compressed) in a form of pre-compiled binary files for your architecture. The executable file of the program is usually in a single folder next to other files (dynamically linked libraries etc.) This whole folder can be copied, with root privileges, either to
/opt
or/usr/bin
and could, if permissions allow, be used by any user. I myself put the folders with binary files into my home folder to~/bin
. Now you should be able to run the program by invoking its bin file.
There are two ways programs can be installed, depending on how they are packed.
Via the software manager (apt, synaptic, Gdebi etc.) – the program is in a form of package, usually .deb or rpm. Software managers in most cases handles dependencies and will install binaries usually into
/usr/bin
, config files into/etc
and so on. They may also create a config file for the program in your home, usually~/.foo
. If you can edit this file, you can also easily change settings for your session this way. When you remove the package, the manager will find all the files and cleanly remove them (it stored all the locations in a special text file). But it may preserve some config files, for example the one in your home folder.You download a program (usually compressed) in a form of pre-compiled binary files for your architecture. The executable file of the program is usually in a single folder next to other files (dynamically linked libraries etc.) This whole folder can be copied, with root privileges, either to
/opt
or/usr/bin
and could, if permissions allow, be used by any user. I myself put the folders with binary files into my home folder to~/bin
. Now you should be able to run the program by invoking its bin file.
edited Nov 4 '16 at 4:23
techraf
4,213102141
4,213102141
answered Nov 4 '16 at 3:51
Štěpán DoanŠtěpán Doan
11
11
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f127076%2finto-which-directory-should-i-install-programs-in-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often
/usr/local
) OR on how to create your own package for it.– Leiaz
Apr 29 '14 at 11:31
Thank you Leiaz. Your comment helped me to find the answer (askubuntu.com/questions/1148/…). So I guess it should be /opt in my case (Using Linux Mint, which is based on Ubuntu) and the application is using a single folder. If you convert your comment into an answer, I will accept it.
– Eiver
Apr 29 '14 at 11:41