Some Practical Advice
@Quantum7’s answer gives a fine literal interpretation of Conda’s conflict reporting. However, I wanted to offer a more practical take, which is that this “feature” from Conda is too non-specific to be useful in most non-trivial environments. And sometimes it won’t even include the underlying conflict. Don’t waste your time with it!
Conda’s Conflict Reporting is Not Helpful
On the face of it, Conda attempts to report all possible sources of conflict. That is, all sets of paths in the dependency graph that begin from the explicit specifications and end in the same package. This amounts to most of what is reported being innocuous and frankly distracting. For example, the zlib “conflicts”:
Package zlib conflicts for:
samtools -> zlib[version='1.2.11.*|>=1.2.11,<1.3.0a0|1.2.8.*|1.2.8']
samtools -> curl[version='>=7.59.0,<8.0a0'] -> zlib[version='1.2.*|1.2.11']
Since samtools depends on zlib both directly and indirectly (mediated through curl), this comes up as two alternate paths that lead to constraints. The problem is that the intersection of the final constraints are not empty, such that there is nothing incompatible here.
Furthermore, there are cases where none of what is reported is in conflict (e.g., this question or this one), which means parsing through the output could be a complete waste of time.
Try Mamba
Instead, if one is actually concerned with resolving conflicts, I find Mamba to be more effective to work with, both in speed and precision.
# install mamba
conda install -n base conda-forge::mamba
# use 'mamba' just like 'conda'
mamba create -n foo instrain awscli samtools python=3.8
Unfortunately, this example simply works now. However, there are other questions where Conda and Mamba unsatisfiability reporting is compared, e.g., this question.