I wasn't proposing to outright disallow cyclic dependencies, but just those which resolve to a cycle when specific versions are picked. For example, consider the following two situations:

 1. package A ver 1 depends on package B ver 1; package B ver 2 depends on package A ver 2: this would be admissible and in fact perfectly reasonable, because even though A and B have a cyclic dependency, when you pick versions the cycle disappears and therefore the `D` dependency matrix mentioned above has no cycles
 2. package A ver 1 depends on package B ver 1; package B ver 1 depends on package A ver 1: this means that A ver 1 and B ver 1 must always either be installed together or not installed. This kind of situation leads to cycles in the `D` matrix, and is the one I was referring to.

I believe that a situation like number 2 is silly, since it means that those two packages should basically be the same package, and that it would mainly arise as a mistake in the requirement files for the packages involved. It is not an easy task to detect these kind of situations in general, because the cycles can be much longer than 2, and because the dependencies are expressed with VersionSets; however, they would clearly show up when computing the dependency matrix `D`, and especially when trying to take its inverse.

I think that the options to deal with this situation are the following:

  1. ban those situations, and have some way to detect this condition (this is probably hard to do, and will result in misbehaviour of resolve if undetected)
  2. consider all packages involved in such a cycle together in matrix `D`: we compute matrix `D`, look for cycles, if we detect some then we collapse all rows and columns involved in the cycle (in the example above, A and B are considered as if they were the same package for the sake of computing an order); after this we repeat the process until matrix `D` has no more cycles.
  3. arbitrarily break cycles in matrix `D`: same as above, but we just remove some `1`s in the matrix rather than collapsing entries (in the example above we may arbitrarily decide that package A depends on B, and neglect the inverse dependency)
  4. use the code I sketched in the previous comment, or anything to that effect, rather then using `inv`.

Option 1 is hard to enforce, but it makes the ordering computation easy (and `O(L^3)`, where `L=size(D,1)`); option 4 is less elegant and makes the computation `O(L^4)`, but is more robust and does not rely on special, hard-to-check properties of the metadata; options 2 and 3 allow to use `inv` but require cycle detection in `D` which will also have an impact on performance, plus some additional manipulations.

IMO the best solution would be trying using `inv`; if a `SingularException` is caught (which I expect to be a rare event), fallback to the code which computes the power series explicitly and removes the diagonal each time (we may also issue a warning in that case).