> Alternatively, you implement one package manager on the computer (eg. .deb or .rpm) and create converters to ensure that python eggs ship as debian-system-consistent .deb packages, etc. This is the most flexible approach: it means that only one place needs to change to make installed software match any changes in debian policy, etc; stops the python developers from being locked into deb-format and policy rules, etc. This is what is done today.
What about having say apt/dpkg as the meta-manager and CPAN/whatever plugins for that? So that apt-get commands also search through CPAN and so on. Of course, one is then relying on both the Debian people and the CPAN people to test that the two work well together. I don't think that is such a big issue though, because in the end the individuals who would be doing that testing are the same ones who package and test the stuff in Debian today.