hi.
On Aug 4, 2009, at 3:52 AM, Aaron S. Hawley wrote:
Re: RPM vs DEB (was: melodrama at CentOS?
To me, the most relevant distinction is the system policy of
Dependency
Checking in Debian. For the longest time, RPM based distros did no
meaningful dependency checking (meaning that an RPM was just a
glorified
tar.gz file). Now RPMs have _started_ supporting dependency
checking, but
Debian has had many years to refine the process and tools and
Canonical has
pushed developments in this area even further with Ubuntu.
This is a misconception. RPM can handle dependencies perfectly well.
I don't know how long the feature of "dependency checking" has been
"refined" in RPM -- I don't know what value finding this out would
prove anyway -- but the discussion at
<http://www.advogato.org/article/306.html> from 2001 explains the
confusion.
Interesting. I am not aiming to start some war involving oven mits,
but you seem to be responding to something I did not write. Maybe I'm
missing your point:
I did not say "dependency handling" I said "the System Policy of
Dependency Checking." I know full well, that RPM, as a format is
perfectly capable of expressing dependency information. [Insert devil
and details here]. The problem is not in the format per-se (which was
the point of my original post anyway). The problem is in the System
Policy which guides the People who package the software. In other
words, not having a requirement for articulating dependencies in a
systematic and automated way.
I have a great deal of respect for many of the people on advogato.org.
However, the post you offer is an ancient blog post. Ian Murdock spent
a fair number of words trying to calm the RPM vs DEB wars. In the end,
package management is the point, not the flavor of package management.
See: http://ianmurdock.com/solaris/how-package-management-changed-everything/
Instead, I've met more people who use RPM for their work than dpkg.
Perhaps RPM is superior by being more practical and easier? Is there
anyone here who actually uses dpkg for one's own packages or for
unleashing changs to machines? Perhaps we can clear this up quickly.
Why are you asking? Are you trying to identify technical superiority
through a popularity contest?
Those who use Ubuntu or Debian, or who deploy systems based on the
package management systems of these distributions will most definitely
use dpkg. (And yes, I use dpkg whenever I compile a new kernel under
Debian.) Likewise those who need to support RPM will use RPM. Just as
those who need to support Windows will support Windows. The same is
true for Portage, MacPorts, etc, etc, etc.
RedHat has much of the "Enterprise Linux" space, IMO because RedHat
offers "support." In other words, they are willing to bridge two
cultures: the FOSS folks (who rely on their communities) and corporate
dwellers who are willing to pay a company to support a product (and to
pay a lot of money to guarantee that said vendor will continue to
exist in the future). The values of these two approaches are both
valid, the point is that they are different.
The recent blather about CentOS on the O'Reilly site is much ado about
nothing, and I am surprised to see such a poorly informed opinion post
masquerading as some kind of recommendation. But I digress.
For those who've read Clay Christensen's *Disruptive Innovation*
series of books: http://en.wikipedia.org/wiki/Disruptive_technology
you will probably notice the difference in values between the FOSS
organizations and the traditional corporate cultures. Those values are
changing, and more and more people are learning the value of FOSS in
business--- and not for the weak argument of cash-outlay either, but
for the much more substantial freedoms granted by the Free Software
(and many OSS) Licenses.
As I've noted previously on this ML, the real benefit of FOSS for
corporations comes from the dramatically reduced maintenance costs
(because the costs are shared across many diverse organizations). See: http://www.dwheeler.com/oss_fs_why.html
and http://www.interweft.com.au/papers/coopetition.html
Thanks.
have a day.yad
jdpf
