Determine destination location of apt-get install ?
For some applications its fairly easy enough to locate where the application was installed to using the «which» command. However, some applications such as Tomcat are a little out of my league to locate. I’m asking for particular methodology that can be applied to any apt-get install to locate where the binary, library, and support files are installed to. The cause of this question is that I installed Tomcat7 and I can’s seem to locate it and I have a list of customizations to perform.
Note that I found where tomcat7 is installed soon afterwards by installing apache2 and then visiting the default page @ localhost:8080 but there is more than that which is shown on that page. Searching the filesystem via the «search:» option in the folder browser found plenty more.
4 Answers 4
You can run the command dpkg -L package to list all the files in the package. For example dpkg -L ubuntu-minimal will only list a couple of small files related to packaging, as it is only an empty meta-package that depends on other packages.
is probably what you want.
That’s exactly what I was looking for! I’ll have to read up on man dpkg since I’ve been neglecting to do so as it seems.
This is a lifesaver for an unfamiliar java library! I didn’t even know the name of the file to look for with locate . Now I can update my classpath.
You can list the contents of an installed package with the dpkg command, which is the low-level package manipulation command that the APT tools call internally:
You may want to search in the output; use the grep command. For example, to see the configuration files (which live under /etc ):
The files you want to modify may be in dependencies of the main tomcat7 package. Searching inside a package and its dependencies is more complicated. It’s likely that the files you’re looking for are in some package called tomcat7-something . The easiest way to display them is with the apt-file command, which is not installed by default (install it with apt-get install apt-file ).
apt-file lists file names in all packages in Ubuntu (according to the package sources you have enabled), whether they are installed or not. You can also use it to search for a file:
$ apt-file search RequestInfoExample.java tomcat7-examples: /usr/share/tomcat7-examples/examples/WEB-INF/classes/RequestInfoExample.java Installing packages into local directory?
The purpose of this exercise is to isolate independent builds in my continuous integration server.
I don’t mind compiling from source, if that’s what it takes, but obviously I’d prefer the simplest approach possible. I tried apt-get source —compile as mentioned here but I can’t get it working for packages like autoconf. I get the following error:
dpkg-checkbuilddeps: Unmet build dependencies: help2man
I’ve got help2man compiled in a local directory, but I don’t know how to inform apt-get of that. Any ideas?
UPDATE: I found an answer that almost works at https://askubuntu.com/a/350/23678. The problem with chroot is that it requires sudo. The problem with apt-get source is that I don’t know how to resolve dependencies. I must say, chroot looks very appealing. Is there an equivalent command that doesn’t require sudo?
@kamil, it’s not. I’m not trying to install without network access. I’m trying to install without sudo and into a non-system directory.
If you don’t have root on the system, you will not be able to resolve dependencies easily. It is sometimes possible, though; you would have to start installing the software in your home, starting with the bottom-most dependencies, and modifying your LD_PATH so that programs can find their libraries. However, you will fail if any of the packages requires root (or suid) to run.
@January, I’m trying to compile a software project inside an automated build system. As far as I know, none of its dependencies (required to compile) require root.
Well, then install the dependencies one by one manually. I don’t see another solution that does not require root.
3 Answers 3
This is, in general, not doable, because you would mess with the apt dependencies system.
- Install the source package, change into the source directory, configure and install the package irrespective of the packaging systems manually to a directory of your choice.
debootstrap precise myfancyinstall This looks promising. Using apt-get source without —compile seems to suppress the warning about unmet dependencies (allowing me to resolve them myself)
Solution (2) will work regardless. Otherwise, you are on your own: maybe there is another way of installing package. Or download the deb package file and unpack it with ar: ar vx mypackage.deb . Then analyse the contents of the package and find out how to install it manually.
using a bash shell, and acquiring the «package.deb» file (assuming pack name is «package») you can run the following command to accomplish what you want — installing the package so that your home directory is treated the same way «/» would be treated in a normal install.
apt-get download package; dpkg -i --force-not-root --root=$HOME package.deb You might face some errors, such as $HOME/var/lib/dpkg/lock is missing so just create all the missing files you will get from the errors and then the install should work without sudo.
notice that if «apt-get download» doesn’t work, you can try «apt download» or «apitutde download package».
if neither methods work, you can just download the package manually from http://packages.ubuntu.com/
another method would be to run the chroot command with the parameter $HOME and then installing the same way as above only without —root=$HOME. that command would bring you in a shell where «/» is your current $HOME. to return to normal mode don’t forget to «exit»
Please note that man dpkg mentions that when using the —force family of options the following applies: «Warning: These options are mostly intended to be used by experts only. Using them without fully understanding their effects may break your whole system.»
If you’re on a shared web-hoster with ssh access but no apt-get no root etc. or a similarly restricted system the following may work for you. It worked for me on a system where uname -a returned something like SMP Debian 4.9.65-3+deb9u2~bpo8+1 (2017-01-05) x86_64 GNU/Linux
# examples tried on a shared hoster with ssh access but no apt-get no root etc. # http://mirrors.kernel.org/ubuntu/pool/main/g/gawk/gawk_4.1.3+dfsg-0.1_amd64.deb # https://github.com/dvorka/hstr/releases/download/1.25/hstr_1.25-1_amd64.deb debURL="http://mirrors.kernel.org/ubuntu/pool/main/g/gawk/gawk_4.1.3+dfsg-0.1_amd64.deb" # get the filename only, remove all till last slash "/" # see http://wiki.bash-hackers.org/syntax/pe#substring_removal debFile=$ # change to your desired directory for installation/unpacking; here: $HOME cd $HOME # get the .deb file (no dependencies checked or resolved here) curl -OL $debURL # unpack only the data part from the .deb file # see https://en.wikipedia.org/wiki/Deb_%28file_format%29 ar p $debFile data.tar.xz | tar xJv --strip-components=2 -f - rm -v $debFile # clean up echo "Done unpacking $debFile into $(pwd)" 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 the 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 another suggested /usr . So which one is «more correct»?
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.
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.
The convention is bad. Ignore the convention. Make ~/apps or ~/programs and put your programs in there. Make ~/apps/binaries or ~/apps/on-path , add that to your $PATH env var, and symlink the programs you want into binaries .
@iono Convention is good when you’re installing a package that will be used by more than one person. Installation in /usr/local is globally accessible, installation in ~onealdw/apps cannot be accessed by any user other than myself.
Yes, I was asking here about a program, which would run as a service (daemon) (even when all human users are logged off), not a personal app that some user would run from their home directory.
8 Answers 8
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 Arch Linux, 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 conventions.
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. )
Usually you put your downloaded folder in /opt and create a symbolik link from /usr/bin. If the app has a GUI a very useful thing to do is to create a NAME.desktop file in /home/USER/.local/share/applications such that you will see it from the main menu. unix.stackexchange.com/a/103222/130710
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