I have thought on this for quite some time and I think there’s a lot of things to do. I’ll try to explain why I think so. I might make mistakes, specially with debian packaging system as I’ve barely used it; if I do please ping me back.
Today the mainstream packaging systems are built on top of legacy ones (RPM, deb), and lack very basic features. One example is rollback. Let’s say I add a custom repo that replaces some of my packages with development versions, I don’t like it, so I just want to go back to the previous state. One might think such a very basic operation should be easy in this fantastic world of Linux, and one would have thought wrongly. Nor RPM nor deb allow that kind of thing.
All right then! Let’s try to list all the packages that came from that repo. Hmm, again, you are out of luck, nor RPM nor deb(?) have a concept of such a new thing as package repositories.
Of course there are workarounds, but if very basic information as where the package came from is not available what can you expect from your package manager?
- Can I find the packages I installed, those that came from upgrades, or the ones that came pre-installed? No. Well, perhaps if you write them down.
- Can I find the unused packages? Of course! you just need to write an application that does that.
- Can I store my system for later restore? It might be a little hard, but you can write an application.
Well, this is Open Source, someone must be working on adding those features right? Wrong. These are not priorities , basically if you want that you shouldn’t use RPM/deb.
So IMHO the future package manager should provide the following:
- Repository support integrated
- Rollback support
- Existence information: added by X (pre-installed,root,john), from Y (repo/url/file), because X (upgrade/dependency)
- Log history
Imagine the following use case: You have the feeling that there are a lot of packages that you are not really using, instead of going manually through all of them you just want to see the ones you installed and their files haven’t been accessed in a while. Once you have that you want to remove the package and all it’s dependencies, this is tricky, so perhaps a GUI with a three of these packages would help.
The future packaging system
In summary, it’s a bad idea. There’s no way a new packaging system will succeed right now. You need a successful distribution to go with that, otherwise not many people are going to use it.
Can you use Ubuntu without debs? Fedora without RPMs? Gentoo without portage? (perhaps yes, but it would be like Linux From Scratch)
Personally I hate these wars. Fedora/Redhat has its own system configuration applications, it’s custom theme, configuration, etc. The same goes for Ubuntu, SUSE. Every distribution is doing the same thing over and over, and they don’t like to share things, or, at least they don’t make it particularly easy to port their stuff.
If it’s all about freedom then why I can’t I use Ubuntu without debs? There’s nothing that prevents RPMs to do exactly the same job. Packages are tarballs with extra information that allows certain operations. You can use alien for example, to convert one to another.
In fact you can install the debian packaging system in Fedora, or even Gentoo. The same goes for RPM inside Ubuntu. Of course, both expect you to have the whole system managed by them, otherwise you’ll have issues, and don’t even think about interoperability.
It’s software, yet it looks like we are talking about Capitalism vs Socialism or some issue of that sort; you must pick one side and never look back.
Liberation: Step 1
The problem is that we are lazy. Are you familiar with this?
Most of the software assumes it’s going to be installed in /usr or /usr/local. That’s a valid assumption, since most distributions do exactly that.
But what if I don’t have permissions? What if I don’t want to mess with my system?
Most of the time you can install things anywhere you want, you just need to know a couple of tricks. But sometimes it’s very difficult.
Problems arise when you deal with system software, basically when you are doing your own distribution .
There are ways to for example install Apache, PHP, and MySQL under /opt/net, and when you don’t want that just remove it. Or you can have /opt/python-2.5 and /opt/python-2.4 and choose the one you want to use when you start certain Python application that requires one or the other. This of course is not that smooth.
What about /opt/gnome-2.20 and /opt/gnome-2.18? You could easily switch from one another.
Since it’s not that easy you’ll need tools to do the switching.
Liberation: Step 2
Another problem are the build systems.
Let’s compare the guts of the glibc package in the different packaging systems:
- RPM (Fedora 7): 
- Note the ugly hacks, and the usual hugeeeeee ChangeLog
- deb (Ubuntu Feisty):     
- Note that you need several files, and a huge file lists for each sub-package (libc6-doc). At least Fedora’s mess was in one single file.
- Portage (Gentoo): 
- It looks better, but still it’s too simple
This is how LFS recommends to install libc  (Much simpler).
A good package build system would make things easier for adopters, and perhaps if it’s independent of the package management system will make things smoother. I am kind of working on an object oriented approach, but nothing real yet 
Liberation: Step 3
So this is what I would like: A package management framework. Each part of it modular, so I can use the same UI for different backends. Perhaps different storage methods, and file formats. After all on doesn’t need to depend on the other.
Kind of like this: