There are some programming languages for which exist a package management system:
Is there any other languages with such systems? What about C and C++? (that's the main question!) Why there are no such systems for them? And isn't creating packages for yum, apt-get or other general package management systems better?
Actually some people (of noticeable boost fame) are working hard to create and establish such a system called Ryppl. It is hard to establish such a System for C++, because it has no single player which can dictate it. --UPDATE: Unfortunately it is abandonned.
On your second question, a normal package manager (besides not being cross platform) does not handle the specific needs of developers.
I think that a problem with C and even more with C++ is that they are more heterogeneous languages: even though these languages are standardized there exist different compilers with different options or different sets of supported features. E.g., I remember posting a question about C++ on stack overflow with an example that was working perfectly on GCC / Linux and someone immediately posted an answer saying that my code was non-standard.
Having a package system like the ones mentioned in the question would imply having a common language and libraries that are supported uniformly by all major compilers on all common operating systems. E.g., you do not want to download a C++ package and discover that it won't compile on your version of compiler X because it was developed on compiler Y on another operating system.
I could imagine that a system based on make and configure scripts (as commonly found on Linux, cygwin and other Unix flavors) could work. But why should Visual Studio users adopt it? The same is valid if one started a package system based on Microsoft Compilers (and libraries).
The fact that C++ is a fast evolving language and its standards always take some time before being fully supported by all compilers does not alleviate the problem.
I think the questions we need to ask in order to answer yours are "What do other languages/ecosystems gain from having their own centralized package repository?" and "Does this apply to C/C++?"
I feel the answer to the first question has something to do with the initial promotion of a new language: the early adopters want to make it as easy as possible for newcomers to enter the ecosystem, acquire useful, tested code and contribute back their own. For obvious reasons, the "usage graph" always has a single root - the creator(s) of the language. There's usually one reference implementation (at least initially) and therefore any code you might want to share has to conform to it.
This makes it easy to create packages that just download and compile. Certainly, had C or C++ been introduced in 2013, their communities could have followed a similar evolutionary path, but they hadn't and there's no one single prevailing toolchain to apply a package manager to. This makes the implementation of such a program too troublesome to be worth the hassle. (should you make users choose between libfoo-gcc and libfoo-vs? Do you leave it up to the packager to resolve? Or the build process? If so, how is a package any different than a straight-up tarball?)
So to sum up my answer to the first question, I think the pattern of creating package managers serves mostly to drive adoption.
With that in mind, I think it's fairly easy to see why no single system has risen to fulfill this need - because the need doesn't exist for C and C++ programmers. What does constitute a problem for the C and C++ community (or any programmer community, really) is the need originally implied: to distribute, keep up to date and contribute back code. This has been solved many times by different people with varying degrees of success, and indeed one system is gaining significant market share: git (and some other systems before that).
Basically when the problems differ, the solutions look different too, but IMHO the difference between typing gem install and git clone is moot.
There is a little confusion in this question. The above mentioned software manage extensions for specific programming languages. They provide libraries and source code that afterwards can be used in you program with your programming language of choice.
While general system level package mangers usually provide binary packages that can be used regardless of the application. They are more oriented at the system and user. Of course, system level package management systems like Aptitude, rpm, Entropy can provide any package, being it binary or source code. That's why you will find in them most of the extensions you would install with ... Gem for example.
Than, what you mentioned as Yum and Apt-get or Rigo are just user interfaces for the package management systems below them.
One more for the list o programming languages:
I realize this is not a cross-platform solution, but it should be added to the mix.
CoApp recently announced support for C++ package management using NuGet: http://blog.nuget.org/20130426/native-support.html
This currently only works with the Visual Studio compiler, but there have been many requests to get this working on other platforms.
