I should point out that Mike is working on something meant to replace RPM and DEB packages, which is why he delivered that glancing insult at them :-)
lol, well our stuff won't be ready for a while yet, and I didn't mean for it to be an insult. As it says on the FAQ on our site, we're not intending to replace RPM or DEB, far from it.
Anyway, there's not much intrinsically wrong with RPM or DEB themselves, the main problem is that you have to make them for each distro, although source rpms can be fairly neutral (ignoring dependancy naming etc) you still have to tweak them for particular distros usually, which is rather sucky. That's more a Linux-wide problem though rather than an issue with those particular packaging systems.
There's also the LSB package, which solves all dependency problems by requiring the package to be linked statically with anything it needs that's not defined by the LSB. I rather like this, but Mike hates it.
It's interesting, I was just talking to Doug Beattie about this very issue, he picked up on a mail I sent to the CrossOver list and suggested maybe Wine could become LSB compliant. That's certainly a good long term goal (and i've considered working on it myself) but yeah, statically linking everything is a super-ugly solution :( Maybe it'd work OK for Wine, I'm not entirely sure how many dependancies it has, but I'm not sure it's many more than what the LSB standardises.
Given the current threading problems, I kind of suspect the LSB can only solve some of the problems related to portability of Wine on Linux.
Now that distributions are becoming LSB-compliant, it's time for people to consider packaging their apps as LSB packages, I think. When and if Mike's effort becomes "Son-of-LSB-package", it will just reduce the bloat associated with static linking, I think.
There are a whole load of issues that need to be addressed really, the static linking thing is only one of them. At some point this week I'm going to try and get the new packaging group underway, focussed at first simply on improving the LSB RPM system so it can have dependancies. Anyway, that's a bit OT.
It'd be good to have an LSB package of Wine available, that'd certainly ease the burden of packaging. You'd still need at least two for the different glibc versions though, I don't think there's any way around that until the transition to the new glibc is over :( Maybe Alexandre can work some magic so that one binary of Wine can deal with both, that'd be pretty good, but I think the answer is it'd be a compile-time thing.
thanks -mike