well, yes. anyway, this part is quite easy, i guess.
so, is the database update part so hard? is it some sort of a weird format that rpm and apt uses or what? i mean, why hasn't anyone yet done it?

Well, I don't know, but nothings stopping us from doing some research, aye? (:

So what we probably want to support is rpm, deb and tgz + source installs. Source and tgz are a piece of cake so that leaves rpm and deb as problematics. So, if youre interested in this, I suggest we both do some research on the subjext and report our findings.. (:

Concerning the rpm db API:
http://library.n0i.net/linux-unix/pr...up__rpmdb.html

The dpkg site is pretty awful, so I guess theres not much to be learned without installing it and excavating.. d:

Perhaps the manpages will help more..

The reason we have package managers is to install/uninstall programs and manage dependencies. Mac OS X evades this problem by including the same libraries on every machine, then make the app include a copy of whatever other library it might need. Problems with this would be that a lot of opensource projects probably don't want to have to include and maintain their own version of a library, it would take far more disk space than necessary, and it would up ram usage (i think, im not sure about that last one). The windows way of installing software I won't cover, both because i don't really understand how it works and its not that great anyway. I actually forgot what i was gonna say after that, it took me awhile to write this since halfway I did a stupid thing on my computer. Yeah I ran the following command-
open /Applications/*.app

Also as a sidenote, I don't think binaries that include their own libraries are a good idea, they would be huge, especially since you would need to make fat binaries so they run on multiple cpu architectures. Yeah, making all the distributions include a basic set of libraries would fix some of that problem, but would be far from ideal. Isn't there like a linux standard base or something that already does that?

you guyes are missing the fundamental function of what the distributors do.
what you are actually saying is each distribution has to have twice as many volunteers to build packages for every conceivable package manageament system on top of doing all the work it takes to map out the constantly changing lists of dependancies needed to make build upgradable syatems with carefully tested packages and packaging systems ??
what could be the possible reason for doing that ?

the people i think in Brazil build apt4rpm or whatever it is adn that does in fact do everything you say. When they built it they also had redhat style systems downloading dpkg packages. But what's the point ?

RedHat and redhat like systems hold on to rpm rather that using dpkg for marketing reasons.
If you use rpm based system you do so for those same marketing reasons.
like the guy said earlier -- choice.

The problem is not marketing in my opinion. Its more technical in some aspects e.g. the Debian guys saying their system is better and vice versa. This leads to the point where you realise that standard package mangement is never going to happen because people simply like different things or think their methods are better than others.

As for creating a tool for updating all databases, its a long shot from working. Firstly you need to install dpkg, rpm and whatever other package management systems that are out there which. You then have to create a system that knows when a package has been installed from other package managers and you also need to develop a unified way of querying info from all these databases etc. Its not an easy task and I am sure thats why so far many people have not tried to develop a unified package manager.