Richard Hughes recently proposed to use D-Bus to abstract the package management solutions for Linux. He implemented the abstraction in the “PackageKit” layer and showed a working GUI.
Richard Hughes proposed his idea some weeks ago by listing several problems of today’s software management on Linux systems: if you update with the help of a (X-) GUI a crash of X can result in serious damage of the package management database. Also, the current tools are all distribution or apt/yum/etc. specific and make it harder for users to switch between the distributions. Another issue is locking: you cannot update, install and check at the same time or with different users. And last but not least there is hardly any form of fine grained user control there.
Richard now suggested to use a D-Bus based solution: a system service would – on the one hand – talk to Yum/Apt/etc. which would be the backends used to perform the real tasks, while the system service would – at the other hand – talk with the user space program via a D-Bus API. The system service would now queue all calls and queries and perform them one after another.
Thus, a X crash would not create any problems, and the abstraction would make it possible for GUI designers to concentrate on the GUI and not on the underlying backend. Last but not least the system service could handle the queue itself and therefore locking would not be an issue anymore.
He called the solution PackageKit.
In the current state PackageKit already implements asynchronous search with Yum or Apt as the backend. There is also a CLI application working asynchronous or synchronous. There is still a lot to do (especially the Apt connector needs some love, not to mention OpenSuse’s zypper or Mandriva’s urpm), but the basics are working and first GUI proposals where brought to real life. There is a demo application showing results of a search query, and there is a system tray applet showing available updates:
I do like this idea very much – it would make it certainly easier to manage software in general if the mean bits are abstracted away. Also, using D-Bus for such tasks seems to be the way to go (to me D-Bus is mentioned a bit too often lately to solve various Linux problems – the “D-Bus is better than 42” approach is a bit strange, not every problem is a nail if you have a hammer; however, here it looks right).
However, I would still prefer to see a general software management abstraction API to perform more tasks than just translate calls and queries – think of installing 3rd party packages or additional repositories here (there are lots of problems). But I think such an abstraction as mentioned here would solve already enough issues – and might also be a base to talk about further improvements.
In any way the main question will be if the abstraction will be picked up by the distributions or if these will stick to their home-grown solution. But the independence from X and the queue idea might give the necessary push. I’m looking forward to see it in Fedora.
/home/liquidat 
This all is very confusing to me for some reason. So this is trying to provide a single Dbus API for package managment, so one frontend can do anything. Sounds like a great idea, but how varied some of the package managment systems are would cause a problem. Portage comes to mind.
Skeith: I guess it will be up to the maintainers of the different software management programs to provide the possibility to connect the backend to the abstraction layer.
In an way, the abstraction seems to aim at the usual user. All distributions for these users use software managements which are basically the same in terms of features and ways of how they work. This might leave some more specialized software management tools outside, but you have to wait until the tool reaches some usable state.