I've long thought the better mechanism is to hook into the destination platform's native package system. A la BSDPAN.

[Such that installing your language-specific package causes appropriate entries to appear in the system's global database of installed packages. Thus making it easier to identify candidates for upgrade, ensure dependencies are correct, remove redundant libs and so forth]

Hear, hear.

Though I believe the best way to make that happen is to make your language play nice with automake. Nobody believes me.

I believe you. This is why I don't use CMake / SCons / Jam / etc -- they're nice for developers but bad for the package maintainers and sysadmins.

CMake is widely distributed now if only because of KDE, so the package maintainers and sysadmins have figured it out one way or the other already.

I'd love to see support for writing directly into distribution's package managers' databases added to things like pip, npm, gems, etc. too but I'm curious what playing nicely with automake gains here. I'm not too experienced with it, and I don't quite see where it would fit into that process.

I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely?

Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.

Automake is most definitely a build tool, and I believe that should be orthogonal to the package manager (even though we're seeing convergence in this area with things like go, virtualenv, npm and so on).

The thing with automake is:

1. Distros know how to package it. With cdbs, a debian/rules file for a properly autotooled package is only a couple of lines.

2. Because everything boils down to shell and makefile fragments, you can extend it to fit your corner cases fairly easily.

Even fink uses cmake to build and install a whole bunch of packages now.

The future, it's not with automake.

I believe most of the point is not in installing such packages into system libraries. The point is easy and fast installation into a virtualenv, avoiding the whole recompilation of exctensions phase.