I don't mind things having their own packaging solutions, because it does get over a hurdle of trying to use things that have broken or non-existent package management systems (I'm looking at you Windows and OSX). What I do mind is when there's not an obvious way to work with the language's provided packaging system to make rpms or debs. Or the language's packaging system actively works against other packaging systems because it's, uh, "unpythonic" or it's just not way it's done in our environment because we're special. The whole idea of a "this is a pythonic packaging system" seems to say "all other previous packaging systems python has used have been unpythonic", which wasn't the case when the previous packaging systems were released -- everyone claims theirs is the best. It's good to have the ability to install things without the system packager (say, in another directory for testing or development purposes), but when it comes time to productionize something, the language's library management needs to work with the system packager.

I think ruby is especially bad in this regard. There's some mindset that seems to say everything should be manageable as if it was a gem, even if it wasn't installed via gem. gem seems to be used to manage dependencies within the library itself, which breaks if the library itself isn't managed with gem. So you sometimes need to fake it (admittedly, I have not installed ruby libs in a while, but I had to make http://github.com/thwarted/gem2deb to make this mildly more manageable, but that's still only a 90% solution and that last 10% is particularly annoying).

perl is an example of one that gets it close. In most cases, you can do the build and stop before the install. Then the contents of the blib directory are the entire contents that needs to be installed, so you can just package that up -- this makes it compatible with all popular system packaging systems. And even then, we have cpan2rpm that does the heavy lifting of scripting finding the package on CPAN.

Package management is pretty much a solved problem, and it's solved for the general case of putting files in place and asserting (and resolving) dependencies -- assuming all the dependencies are packagable/available in packages (which is easy to achieve if things can be easily packaged). If you think you need more than that, it might be time to revisit how your libraries are written and how your language uses libraries. If it's anything more than "are the files in a place where the language can find them", it may be time to revisit it.