2 dominant, incompatable desktops is imposible.
As we know, Windows is currently the dominant desktop. 90% (or so) of all programmers are doing Windows only programming. That is because it is much easier, has a faster developmenet time, and cheeper to do only one version of a program. Since GNOME and KDE are incompatable, when Linux becomes standard, there will be one dominant desktop environment, and the other will either die, or linger around like amega haveing support from only a small group of people. One of the two Linux desktops will eventually gain Defaulthood unless GNOME and KDE become component compatable. IE, you can embed gnumeric in kword. This would only happen if GNOME and KDE could agree on a common component model. I've studied both Bonobo and Kparts, and have come to the conclusion that Bonobo is the way to go. Kparts is nonstandard, it is not langauge independent, it is QT dependent, and doesnt support distributed computing. Bonbobo on the other hand uses CORBA under the hood, so it uses standard technology, it is language independent, it is not any toolkit dependent, and supports distributed computing. If KDE picked up Bonobo for its component model, GNOME and KDE would no longer be competing, but complementery. This is the only way I can see getting around one of GNOME or KDE eventually dieing off.
Universal Package Management
Well, getting everyone to agree on a universal package manager would be like makeing everyone use the same distribution. It would be nice, but its not going to happen. So, the problem becomes, how can we make it so that we only have to create one package file that will build packages for any distrib.
Create an xml based package description format. Similar to how a rpm spec file works.
Every package manager works almost the same. They all describe what the name of the package is, version number, files to install, etc.
Then, there could be a xml->native converter that parses the xml file, and generates an rpm spec file(or whatever that dist or os uses) to produce a working package for that type of system.
I know what your thinking. Each platform has slightly different properties so this wont work. Already thaught of that.
In the config file for upm, there can be system spacific variables defined. For example, prefix. Redhat uses /usr. Others use /usr/local.
In the xml file, you can also override any of the tags in it, with system spacific tags as well. For example, something like this:
Also, these variables could be over ridden by the command line.
So, heres how it would work. You find a program that you want. Say, gftp.
There is no solaris pacage for it, so you download the tarball (or upn could pull it down itself).
your run something like:
upm -b gftp-whateverver.tar.gz
and it will extract it where it needs to be acording to the way your system works, extract gftp.upn (the xml file) and generates the apropriate package description file for that system, and then builds a package for it.
Also, we could get something like apt going. but make it 2 way. not only could it pull down a package, if you build a package in the way described above, it could upload the generated package back up to a contrib server so that someone else wont have to build it.
The last problem I see is that most programmers dont like to deal with updateing spec files. The result is that the source will compile and install, but everyone who wants a package needs to edit the spec themselves and rebuild. Rather ugly. To solve this problem,
an extention to automake could be devised. Since automake knows where a file will be installed, the Makefile.am's could be used to generate package file content lists for the rpm or other package. That way, the programmer wont have to maintain the list. It will be automatic if they are useing automake.
This is just an idea, and probably has a few design issues to work out, but it seems like a sound idea. Just will take a bit of work to implament. (dont look at me. I already have too many projects to work on. :) If someone wants to develop this idea, contact me and I'll try to help as I can.