Ubuntu – Where does “The program ‘‘ is currently not installed.” get its program list from

Does something similar apply to linux where all programs are installed in a central place

Approximate equivalents of Windows install directories in Linux

• \Windows = /bin
• \Windows\System32 = /lib and /sbin
• \Program Files = /usr/bin and /usr/lib

I would prefer to keep all my installed programs in one place so what is the right place for this in terms of best practice. In other words what is the Linux equivalent of C:\Program Files?

That would be the directories under /usr, specifically /usr/bin and /usr/lib.

And how does one always install at this location, is it just a matter of placing the tarball and running the install commands from this location?

• No. Where you are when you run the install commands almost never matters.

• Programs you install via apt-get (or aptitude) will almost always end up appropriately in /usr. BUT programs you compile from source and make install will more often end up in /usr/local/bin, /usr/local/lib, etc, and you may have problems with that since the user-installed path in Debian/Ubuntu is /usr and not /usr/local.

• When compiling from source, add this switch to configure: ./configure --prefix=/usr. This way when you make install the files will end up in the right directory

• Also look into the checkinstall program, which keeps track of the files a package compiled from source installs, makes a deb file, and allows for easy uninstall/reinstall.

What about if I use sudo apt-get to install a package. How can I point to this location to tell apt-get to always install there?

apt-get/dpkg take care of this automatically. You can use dpkg -L name-of-package to see all the files installed by a package and where they were installed.

Usually this happens when mismatched package versions are hand-installed with dpkg or gdebi without some of the dependencies having a resolution. (dpkg/gdebi and other .deb level tools will try to install a package where dependencies are unmet, leaving it in the half-installed "unconfigured" state, which apt considers to be broken. apt, software center, synaptic, and other high-level package management will usually catch these errors from reading the dependencies before installing the package and stop you before you break things, unless the error happens late in the installation, such as what happens when a package in the repository is broken and tries to write files owned by another package)

So long as the packages causing the error are not system critical and can be removed without causing a huge cascade of dependency problems, the quickest way to resolve an error like that that apt-get can't resolve on it's own is to back the offending packages out until apt-get -f install is able to take care of the problem, then apt-get update, apt-get upgrade, and finally try what you were doing again through apt-get.

In your case, I'd start by backing out libcupsimage2:i386 ia32-libs-multiarch:i386 and skype:

apt-get remove libcupsimage2:i386  ia32-libs-multiarch:i386 ia32-libs skype

If the situation is more complex, and creates huge cascades of failed dependencies, then the alternative is to figure out from the dependency messages what went wrong and try to specify a solution by naming the packages necessary to resolve the dependency problem. Usually these sort of situations arise from mixing packages from multiple repositories such as backports or PPAs, and you solve them by specifying a particular version of a package that wouldn't normally be considered by apt because of pinning, or by explicitly telling apt-get to go back to versions in the official repository (apt-get will not downgrade a package to solve a broken situation unless explicitly told to do so - so if you installed a newer version of a library by hand, and packages on the system have a dependency on the specific version, you have to update one or downgrade the other until the dependency mess is resolved.)