What information do I need to solve an APT dependency issue?

A reasonable first thing to try is to ask apt why it is doing what it is doing. This can be done with the -o Debug::pkgProblemResolver=yes option. E.g.

apt-get -o Debug::pkgProblemResolver=yes install libgl1-mesa-dri:i386 libdrm-intel1:i386

If apt is not forthcoming, the standard approach to debugging such issues is to check the priority numbers of the available versions of each package mentioned in the error message. This is commonly done using apt-cache policy.

For example, to use just the first part of the error message, you should run

apt-cache policy libgl1-mesa-dri:i386 libdrm-intel1:i386 libdrm-nouveau2:i386 libdrm-radeon1:i386 libdrm2:i386 libglapi-mesa:i386

How one proceeds then depends on what this shows. It is often also useful to run just

apt-cache policy

which will show all the package sources available, along with their priority numbers. This information is usually specified in one or both of /etc/apt/sources.list or /etc/apt/sources.list.d.

People trying to get help here should first post the results of these commands in their question. That will likely be enough information to determine the problem.

Real-life examples of problems:

1. Unmet dependencies after using a backports repository: The user included sources for www.deb-multimedia.org, without pinning it to a lower priority. Never include third-party sources without pinning it to a lower priority. Note that this should not be necessary for well-behaved repositories which provide packages for the default release, but www.deb-multimedia.org is well known for not playing nice with Debian, and in general, you should not trust unknown sources. More generally, if you know a repository is not designed to be used with your system, pin it at a lower priority. E.g. testing/unstable sources on Debian
   stable.

2. Unmet dependencies: The user somehow managed to install a version of python that wasn't the default version on his system. Naturally, all hell broke loose. Moral of the story, make sure you are only installing versions of packages that are correct for your system. As above apt-cache policy pkgname will tell you.

3. dpkg / apt-get wants to install and overwrite different package: The user tried to install packages even though his underlying dpkg database was broken. Moral, if you see messages coming from dpkg that something or the other is wrong with your packages, in this case

   0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. 2 not  
   fully installed or removed. 
   

   your package database has problems. First fix them, before you try to install anything else. If apt-get -f install doesn't work, you may need to operate at the dpkg level to fix things.

There's a bunch of information that would help you:

1. Include the complete command that caused the issue in first place.

2. Include information about the packages involved with:

   apt-cache policy name-of-packages-involved
   

   So, in your case is the output of apt-cache policy libgl1-mesa-dri:i386 libdrm-intel1:i386 libgl1-mesa-glx:i386 libdrm-nouveau2:i386 minimum.

3. The output of sudo apt-get check and possibly sudo dpkg -C also improved the chances you have.

4. The complete output of sudo apt-get update and cat /etc/apt/sources.list{,.d/*.list} can help in certain situations. In case you are trying to install a package, the output of aptitude's why-not command to easily figure out:

   aptitude why-not sysvinit-core
   i A systemd-sysv Breaks sysvinit-core
   

When asking for help about solving this issues, always include the full output of everything asked, this would expedite the solution of the problem.