CPAN's success, as with Debian's, is not due to the technical infrastructure but rather the social infrastructure. There are plenty of ways to make packages not work at all, it's just that the Perl people don't do that.
(If you have ever read the CPAN source code, you would be surprised it works at all. Don't get me started on the various incompatible build systems, and what happens when your module's build system depends on a newer version of the build system.)
Haskell's Cabal is the technical model to steal. Don't let modules execute their own code unless they actually need to. 99.9999% of modules do fine with some sort of declarative interface, rather than actual code to do those things.
Yes, cabal is the thing to steal. Improving distutils is worthwhile, but a temporary stop gap, most fundamental issues cannot be solved from improving distutils. Distutils itself is only 10 000 LOC of bad code, without good API, and you can reuse most setup.py from a conversion step.
It does not do much ATM, except for the conversion step: it can generates a static description of the package from existing setup.py. It reuses distutils to build package, but it does so from the declarative file, meaning that the whole thing is not tied to distutils anymore: distutils becomes an implementation detail.
The CPAN works despite clunky code and competing implementations because the functional decomposition is sufficiently effective. (EUMM is some of the worst code in intent, design, and implementation I've ever read and used anyway.)
The CPAN software infrastructure only works for things that it was intended to do, it is very hard to make it do arbitrary things. If you want to find out what file to download from the BackPAN to get Foo::Bar 0.2, that's too bad, you have to download the BackPAN and index it yourself. Of course, there is no way to index things without evalling code regexed out of every file. (And there is no way to predict if "make install" will actually install Foo::Bar.)
Something CPAN couldn't easily do a few years ago was install to arbitrary directories. If you set the right environment variables, EUMM would sort of do the right thing. If you set different environment variables, sometimes MB would do the right thing. Eventually EUMM and MB were patched so that it almost always worked, and then local::lib was written to paper over the differences.
And of course, nothing requires the use of EUMM or MB, so if a package doesn't use it, you can't install it to your home directory.
Anyway, the EUMM is what you get when you write code to fix problems that people complain about. MB is what you get when you write specs to "fix" problems people complain about. Maybe someday we will have a build system that has a sane design and actually works.
(If you have ever read the CPAN source code, you would be surprised it works at all. Don't get me started on the various incompatible build systems, and what happens when your module's build system depends on a newer version of the build system.)
Haskell's Cabal is the technical model to steal. Don't let modules execute their own code unless they actually need to. 99.9999% of modules do fine with some sort of declarative interface, rather than actual code to do those things.