Etch'd.
Well...that's that (hopefully).

Again, thanks for all your help even though, ultimately, I had to start over. At least now I know a little more about apt-get and it's various components and I know how NOT to handle dependency issues. ^_^
Also, now that I have Etch I was able to install ZSNES from Aptitude without any trouble at all. The only real problem is that for some reason my new setup wouldn't accept alot of the config data I had backed up, meaning I have to manually reconfig KDE, printing, and a few other things.

When you've used Debian for some time, you learn to avoid broken dependencies -- and when they happen, you learn to fix them before they grow so big that you need to re-install.

Debian stable should not have any broken dependencies but installing packages from unofficial sources may introduce breakages.

Debian testing is a moving target and sometimes there are temporary breakages. If you track Debian testing, you should install the "apt-listbugs" package that will warn you of packages that have bug reports filed against them. If the bug reports that apt-listbugs lists are marked as "done", the reported bugs have already been fixed and it should be safe to install the package. But if apt-listbugs tells that the bug report is still "open", then you should consider carefully if the reported bug might affect your system. Sometimes the Debian maintainers are unable to reproduce the reported bug and so they let the package migrate from unstable to testing. So every time when you install/upgrade a package that has open bug report filed against it, you're taking a calculated risk. At least you've been warned by apt-listbugs if something bad happens.

If you track Debian testing and something breaks, you can usually fix things either by uninstalling the broken package, changing sources.list to temporarily point to stable and installing an older version of the broken package from stable. Or you can temporarily point sources.list to unstable and install a newer version of the package. Or you can just wait until apt-listbugs tells you that it's safe to install/upgrade the package.

I've found aptitude to be quite useful tool for this kind of negotiations with broken packages. If apt-listbugs tells you that some package you're about to upgrade has open bug reports filed against it, you can press the "=" key on that package and this tells aptitude to put that package "on hold" and not to upgrade it. And after a week or two has passed, you can press "+" on that package to mark it to be upgraded, so you can test if apt-listbugs still warns you about it.

When you're careful installing and upgrading packages and when you learn to negotiate your way around small breakages as described above, you should never again stumble into the kind of large-scale breakage that you've just experienced.

There's one thing I don't understand, though. If packages.debian.org isn't an official source, what is? That's where I got every package that was requested by ZSNES and it's dependencies... The only thing I can think of to really explain it is that it must have come from some RPM I tried to install with Alien, though I don't know which one it was.

I have no way of verifying that you've installed any unofficial packages -- it was just an assumption I made based on your first post where you write that you've spent all day downloading and installing dependency .deb packages using dpkg. Why would you install dependencies manually when you can just use apt-get or aptitude to resolve dependencies automatically? Unless, of course, you're installing packages from unofficial sources that don't have the required dependency packages.

But, yes, installing a .rpm package turned into a .deb with Alien would qualify as a package installed from unofficial sources and this might well be the actual reason for your broken dependencies.

The most usual reason for breaking APT is that people mix different development branches (stable/testing/unstable) in their /etc/apt/sources.list. (There's a technique called "apt-pinning" that makes it possible to mix branches without breaking APT. Mixing branches without apt-pinning is a very bad idea.) Here's what a normal /etc/apt/sources.list entry looks like:
The "http://http.us.debian.org/debian" part tells APT which download mirror it should use. The "stable" part tells APT which branch you're tracking. The "main contrib non-free" part tells APT which package repositories you want to use.

If you mix branches, your /etc/apt/sources.list might look like this:
Don't mix branches like this. It will break APT because it mixes different development branches (stable/testing/unstable). If you stick to tracking just one branch, you shouldn't have any problems.

Here's some additional documentation:
http://www.debian.org/doc/manuals/ap...basico.en.html
http://jaqque.sbih.org/kplug/apt-pinning.html
http://www.argon.org/~roderick/apt-pinning.html

Hm...Ok. Thanks for all your help. It was...um...helpful!