> rpm includes dpkg-ftp as base functionality (package names are url's :-)
> dpkg-cert, if I understand it, is rpm --verify. alien is meaningless
> when the formats are the same. dpkg-perl: I think there *are* rpm::
> modules in CPAN. as for fakeroot: rpm handles it by letting normal
> users build, and then having a "cleanup permissions" stage at install
> time; crude, but effective, and done a *long* time ago. dpkg-repack
> doesn't seem to have an equivalent (though I've never had a *good*
> reason to use it, only some bad ones) and suidmanager is debatable as
> well, *especially* without things like rpm --setperms, which actually
> lets you make the installed permissions match the package...
>
> So, sure they wouldn't have happenned -- because rpm *already* handles
> them. Of course I don't know the history here -- but *do* try to be
> more aware of what rpm is actually capable of, and argue *that*.
Points taken. But I still feel our approach is superior, because each
capability is implemented by developers outside of the core team. And
when our Debian developers come up with these innovations, they are
usually well thought-out and thoroughly debated. And it's likely
to continue. I could probably double the length of my list a year
from now.
Remember, somebody has paid Erik Troan's salary for the past few years
to develop RPM -- whereas dpkg and friends was developed in a piece-meal
fashion by a bunch of (really smart) volunteers in their non-funded
time. My guess is that there has been a lot less man hours spent
developing dpkg than rpm. dpkg is fundamentally a simpler, better
design. If the same number of man hours were spent on dpkg and friends,
rpm would look really, really pathetic.
I'll debate your points:
* dpkgvert vs. rpm -Va - dpkgcert is still experimental, and it isn't
evolved enough to incorporate certificates into dpkg-deb. It will
happen. The output from dpkgcert is 10x more informative than the
output for rpm -Va.
* dpkg-ftp vs. rpm (using URL's) - dpkg-ftp is really an extension to
dselect, not dpkg. Red Hat doesn't have a real equivalent to dselect.
Glint sucks (we have it too, you know). I tried glitter - it's
trivial compared to dselect. Purp is still vapourware, and it still
isn't going to do what dselect does.
Having http and ftp code in the core packaging tool is really, really
bad design. It's not properly abstracted - it's pure bloat.
* alien isn't meaningless. What alien demonstrates is that dpkg is
essentially a superset of what rpm does.
* dpkg-perl - this is probably just an extension of libdpkg (I think)
- so you are essentially right
* fakeroot vs. rpm - you are right again, but this does demonstrate
the everything doesn't have to be monolithicly embedded into the
core packaging tool
* suidmanager vs. rpm - I'm not particularily familiar with either,
but it's another case where dpkg didn't need to updated to handle
a feature whereas rpm was.
Basically, I think the whole packaging tool business is in it's
infancy - and dpkg is in a much better position to innovate because
it is reasonably abstracted and not too bloated.
Building a package under dpkg is extremely simple and based on very
mature tools (primarily GNU make). It's almost possible to build
a Debian package without using any Debian tools (I think our .diff.gz
files are a bit different for some reason). This gives us the
flexibility to almost completely change the way we build packages
when a better way is found (we've done it before).
Some future innovations we can do without touching dpkg:
* Overhaul the source packaging format to support source dependencies,
upstream source packages, building from .src.rpm's, building
.rpm's from .deb's, etc.
* Develop a "debdelta" package to support more efficient transferring
of package changes. (I guess this could be done with RPM too)
* Finish diety off
* Use expect (and maybe some "expert system" stuff) to script complete
mass installs/upgrades
* 10 other things I haven't thought of yet
More importantly, of course, is that the competition between dpkg and
rpm is really a good thing. It drives innovation.
What's wrong with dpkg:
1) The core developers (Klee Dienes and Ian Jackson) are too busy. I
don't know what to do about this. Perhaps organize something around a
CVS repository?
2) The internals aren't well documented. There are almost no comments.
It takes quite a lot of study for a new developer to figure out what
is going on in there.
3) There's a whole slew of bug reports.
4) It's relatively slow and it takes too much memory to run on a large
system. I'm not sure what it is doing, but I assume it is building
a large structure in memory that holds the dependency information.
This is probably just a sign that some cacheing (persistent) could
be used to speed it up. Of course, the average user only upgrades
once ever few months - so speed isn't really a top concern.
5) It needs PGP checksums in the binary packages. dpkgcert is an
experimental approach for this. Of course, judging from the response
to my dpkgcert.jimpick.com site - it isn't an often-used feature.
Anyways, I _like_ dpkg. :-)
Cheers,
- Jim
Attachment:
pgpPe0mdAhHfv.pgp
Description: PGP signature