How do you find dependencies when installing software?

Each package comes with a list of its own dependencies. For debs, which Ubuntu uses, you can do:-

[andys@daedalus ~]$ apt-cache depends git-core
git-core
  Depends: git

The dependencies for a package are specified when the package is built. Some of them are specified manually by the package maintainer (the person who's responsible for building the package), and some are automatically determined when the package is built. If you download a Debian source package, and look in the debian/control file, you'll see a number of lines like Depends:, Conflicts:, Replaces:, etc.

So, back to the example - git-core depends on only one package, which is git. git is probably a metapackage of some sort, which in turn has a whole raft of dependencies, to make sure all the packages neccessary to run git are installed - not just to satisfy the dependencies of one package. If we look at the git package:-

[andys@daedalus ~]$ apt-cache depends git
git
  Depends: libc6
  Depends: libcurl3-gnutls
  <...snip...>
  Suggests: git-cvs
  Suggests: git-svn
  Suggests: git-email
  <...snip...>
  Recommends: rsync
  <...snip...>
  Conflicts: git-core
  <...snip...>
  Breaks: stgit
  Breaks: stgit-contrib
  Replaces: <cogito>
  Replaces: git-core

...you'll see that git itself has further dependencies. To complicate things further, there's different kinds of dependency other than just requiring another package to be installed...

• Conflicts - this package conflicts with another package, and you probably won't be able to install the conflicting package without uninstalling this one, and vice versa. In this case, git conflicts with git-core. On my box here, the git-core package is marked as obsolete, which is probably why this is listed here.
• Breaks - this package breaks another package, and installing it - although perhaps not requiring you to uninstall the package that will be broken - will cause problems with the software installed by that package. Again, looking at our example, the stgit and stgit-contrib packages will be considered broken once git is installed.
• Replaces - this package replaces another package, meaning that the other package is obsolete and can probably be uninstalled. The git-core package shows up again here.

There are also 'soft' dependency types, such as Recommends and Suggests, which aren't required by the package you're installing, but are recommended or suggested, as the name suggests. Once again, looking at the example, the suggested and recommended packages are add-ons to git, or tools not directly related that will make using it easier.

Putting all this together, the package manager you use will start off with the package (or packages) you've asked it to install, and will look up the dependencies for it, and then any dependencies for those packages, and so on. It will also check for packages which conflict, break or replace the requested packages or their dependencies. Once it's happy that it's found a way it can satisfy your original request, it'll then go ahead with the install.

Different package managers have different ways of doing this dependency resolution. apt-get, aptitude and dselect, for example, all essentially do the same thing but the way they make their decision differs. You may find that aptitude and dselect will happily present you with a way to install a package whereas apt-get can't.

If you're interested in knowing more about Debian packages, have a look at the Debian New Maintainers' Guide, which goes over some of the guts of debs.

usually apt will do that for you. if you try to install a binary package that has unmet dependencies, apt will tell you which ones are missing and ask you for permission to install them as well.

most source distributions tell you in a README file what the -dev dependencies are.