The easiest problem to tackle is .RPM vs .DEB debate that should have ended about 3 years ago. If the LSB had said .DEB it might have happened, but since the "official" standard and the actual majority are diametrically opposed it doesn't want to happen. And of course the filesystems don't perfectly match across distros.
The .rpm vs .deb debate is a fallacy. The real issue is that when packaging for say debian and RHEL you have to care about different glibc, different compiler versions with potentially different ABI, different filesystem conventions, different scripts for post install, etc... The format in which the files are packaged is the least of the issues compared to that. For example, packaging for opensuse once you have a package for RHEL is as much of a PITA than packaging for debian, really.
Once you standardize on what makes packaging difficult across distro, you basically end up with the same system. I think systems like the build service from Suse, etc... are much more useful than wishful thinking on packaging format.
Yes, suse build service is a very nice tool and much more interesting than a single package format, which wouldn't help much. And if the dream is to provide just a single binary package for any distro in the world, it won't work anyway. Well, maybe in theory, but if you mean it seriously, you need to compile and link against exactly the same binaries that the target system use. (Or static linking. Or just believe it will work. But serious commercial vendor who wants to provide a real user support cannot.) Which would mean that every Linux system would have to use the same binaries, which is, hm, nonsense.
Meh, from a source point of view, once I have a debian/ directory, with a properly set up rules file, building becomes trivial. Then it is matter of generating a package per-distro/version with the right environment. This could be very well done in an automated manner and a few vms.
I hear what you are saying, but we can reduce the differences between build systems while still using different targets.
I do a lot of work with OpenEmbedded, every distro image you create is for a different hardware platform, using different libraries, different tools, etc. But it is a unified build system. So I can say use this version of glibc and spit out the files in that folder, and with very minor tweaks I can use a completely different version of glibc and a different file structure for another image. If we had a unified dependency/build system across distros, we could have completely different contents while having relatively straightforward customization because if you knew one system, you'd know them all.
From what I hear, .DEB is a bitch to do anything outside of the norm, whereas .RPM is much easier and less complex of a package format. That said, I much prefer the apt system on Debian, and Ubuntu. What really needs to happen is to take the best of both worlds and merge it into something of a complete system.
I found Pacman to be easy and simple--on the same level as APT, and when the binary package doesn't do what you want, packing your own package is really easy.
upvoted for pacman. I actually have only tried arch at a friend's place, because for some anal reason Arch does not provide livecds. Only a command shell from where you must build your system up, which is quite a pain.
But I have only heard good things about pacman (and it's ultra simple package format). It enables Arch's rolling releases model, which means that you are always up2date without having to go from Beserking Baboon to Chittering Chimpanzee.
It is a much saner model for a stable, usable desktop system. If you can manage to combine this with a kernel update technology like ksplice, you have a super stable, updated Linux desktop without ever having to reboot (which makes the whole splash screen effort quite pointless actually)
As someone who has run Arch on their main PC for a year+, let me tell you it's not all roses. pacman may be simple, but it lacks many features you have come to expect; don't be surprised when everything on your system breaks when you pull in an updated library. Don't be surprised when pacman pulls in a new kernel without noticing, your machine fails to boot because it has nuked all of your old kernel modules.
While I agree that the rolling release model is attractive, it requires a much more robust package management system to be practical for people who do not live on the bleeding edge 24/7.
You should really try Arch. I was initially hesitant, because of the whole 'Build you own Linux!' thing, but after doing it once I learned LOTS and realized that it was not near as difficult as it sounds.
There is excellent documentation in the Arch wiki, and the forums are helpful. And I have to say, installing arch linux taught me more about linux than anything else that I have ever done.
