|Keep It Simple, Stupid|
have you solved the dependencies problem - ie, that that version might break with a newer version of one of its dependencies, or that pinning it might make future releases of stuff that depends on it break?
No, I'm not that smart. Pinto doesn't figure out the optimal dependency graph for you. It just helps you tune the index so that you can (eventually) discover the optimal graph yourself.
Pinning a package merely holds the index to a particular version of that package. That version could break with newer dependencies (although I certainly could implement a recursive "pin" that would also pin dependencies). And pinning a package could make it impossible for cpan(1) or cpanm(1) to satisfy a prerequisite. In either case, you won't know until you build.
So finding the optimal dependency graph is still a trial-and-error process. Manually solving this problem for all of the CPAN is probably not feasible. But I'm hopeful that it is feasible for the average project which only uses a small subset of the CPAN.
Pinto could be used in conjunction with cpXXXan. For example, I could create a Pinto repository to track CP5.12.0AN, and then pin the Pinto repository index to those versions that are compatible with my application. So I'll end up with an index that is most likely to yield a working build of my application on perl 5.12.0.
Come to think of it, you probably could implement cpXXXan itself with Pinto. Basically, Pinto enables you to quickly and easily create whole repositories with arbitrarily (or systematically) defined sets of packages. I'm still figuring out how to actually apply that capability in the real world.