Forgot to say
SPK includes dependencies, but they're done in a way that's different from how most packaging systems handle them. Originally, the idea of SPK was to make it highly portable to already-installed Linux machines. Instead of checking to see if a package was installed, SPK checked to see if the actual file existed.
Erm - that's the way rpm does most dependencies, though it does do package dependencies as well. deb, in contrast. does package/function dependencies exclusively.
There are several reasons why file dependencies are a bad thing: if package A depends on package B, but you don't want B and have found package C which does the same thing, then file dependency means you are stuck. With deb, you can simply make package C provide the package/function name that A wants. For example, the sendmail, exim, qmail and postfix packages all provide the mail-transport-agent pseudo-package.
Similarly, if A depends on B (in a file-dependent way) and a new version of B comes out with changes to the layout of key files then you can't install the new B until A has been rewritten to cope with these changes, even though A hasn't changed at all. Again, package/task dependency avoids this.
We have tried to take the best ideas from both RPM and deb.
Not on the evidence presented in this article.
Missing the point in so many ways
Ho, hum. Another packaging system. "Just a tarball with a configuration file". Much like a slackware package then. Or a deb package, even. A deb package is 2 tarballs (one for the original source, one for the debian patches) and a configuration file. So far, so unrevolutionary.
There isn't a big battle between rpm and deb - they're more or less equivalent and it's no big deal producing either. There is a battle between rpm/rpmfind and apt, one which apt-get wins hands down since a) rpm and rpmfind combined don't even begin to match the power and functions of apt and b) apt is package-tool neutral and was designed to work with any packaging tool that has a minimum feature set. Connectiva have modified apt to work with rpm - a highly significant event, if not one that Red Hat are likely to support since it threatens their fee-charging Red Hat Network.
It should not be hard to make apt work with this new packaging system (which, as described, is no more a rival to apt than rpm is). That is where there's a need for convergence, on the overall package/system maintenance side, and that's what apt offers. On the low-level packaging side of things, there's every reason to continue the healthy competition.