> Well, I think Erik is pretty responsible, but as long as most of the
> developers still like dpkg/dselect, I'm willing to stay with it.
I've got nothing against RPM, Red Hat, or Erik. But I really think
you are selling dpkg short. So here's a short little essay on why
I prefer dpkg to RPM:
dpkg is a completely different philosophy than RPM. I find dpkg to be
more Unixish than RPM - it leaves plenty of room for scripts and
is pretty 'loose'. The developers have immense amounts of flexibility
in how the packages are built, installed, configured, etc. It's very
extendable. Of course, there is a price -- there is potentially more
inconsistency in the packages and in the system.
RPM, in comparison, is quite rigid and restrictive. This is good for
Red Hat, since they are a company putting together a product in a
top-down manner. Any flexibility they need can be designed into the
packaging system on a case-by-case basis. As a result, they can
deliver an extremely consistent set of packages. They can do this
since have a conventional authoritarian organization (a business).
The Debian system is being developed in a bottom-up fashion, so the
'centralized' nature of RPM is totally inappropriate. dpkg encourages
developers outside of the core dpkg developers to innovate. That's
extremely important since we don't all work in the same office. Plus,
nobody is getting paid for this -- the lack of restrictions is quite
nice when you have hundreds of people 'doing their own thing'.
Some examples of packages that we've developed that probably would never
have happened if we used RPM:
dpkg-ftp, dpkg-mountable, dpkg-cert, dpkg-perl, dpkg-python,
debmake, debhelper, alien, dftp, dpkg-repack, dpkg-cross, menu,
fakeroot, suidmanager, cvs-buildpackage, kernel-package
+ I probably missed a few.
There's a parallel: firewall design. You can have a restrictive firewall
policy (everything is denied, unless explicitly allowed), or you can have
a permissive firewall (everything is allowed, unless explicitly allowed).
The restrictive policy has less chance of failure, but incurs a much
higher management cost, and aggravates the users who want to do something
outside of the norm. The permissive policy is easier, has lower management
costs, and aggravates the users less. But it is much more open to
failure.
Both sets of policies are equally valid - depending on the needs
of the organization. I would argue that the RPM philosophy embodies the
"restrictive" policy, whereas dpkg embodies the "permissive" policy.
Red Hat needs a controlled, restrictive packaging system because they
have committed $$$ and have to control the amount of risk they can
expose themselves too. Debian works well with a looser, permissive
packaging system since we don't have a lot on the line, and can afford
to experiment.
Anyways, I feel dpkg and it's related innovative packages represent the
'heart and soul' of the Debian project. Sure, dpkg isn't perfect, or
even all that polished - but it is an extremely flexible and pliable
system. We're limited more by the policies we choose than by any
technical limitations. I like where Debian has positioned itself
(more innovation-oriented -- less product-oriented), and hope that
doesn't change.
Cheers,
- Jim
Attachment:
pgp3uyDivrCCw.pgp
Description: PGP signature