I'm going to dispute Bill's final statement about RPMs in this segment.
RPM will not allow you to install a package that breaks another package(.so bin libs, app binaries, or otherwise), it just won't. Unless the RPM has been mispackaged in it's dependancy list. OR unless you --nodeps it, or --force it.
My point was not that it breaks a package, but that it can (and frequently does) generate a variety of RPM dependency errors, reported back by 'rpm', that need to be resolved before the package can successfully install. My point in this segment is chasing
down these dependencies can take time.
All those latter cases are big no-no's unless you absolutely know what you're doing.
I've managed many Linux admins over the past decade and unfortunately using rpm '--force' or '--nodeps' happens much more frequently than you might think.
When you do update with an RPM updater such as yum, up2date or urpmi, the updater program will scan all the headers from the repositories that are listed in the sources file to try to fill the chain of depdancies for the update, and will solve the RPM's that
need to be upgraded or installed before your target package(s) is.
If the dependancies are not all found in the source headers from the repo's it will NOT install by default to break any system applications you have on the machine.
The difference is that these dependency errors need to be chased down by the user. My point in this segment (and in the other blog reply) was that we do a tremendous amount of work in testing and in servicing so that our customers don't need to chase these
types of low level errors when doing an update or install.
Again, just differences in how we service our software - not a good or bad judgement call. -Bill
up2date systray icon in Gnome. So here we go, up2date, yum, urpmi
You don't know much about linux or rpm or package updaters do you?
We have the equivalent of windows update.
But you are missing a key concept here in the model differences, which is the amount of formal, methodical and deep testing (backwards and upwards) that goes into how Microsoft validates and releases an update and how an update is released via any of the technologies
you list above. -Bill
Hey Beer28, Bill Hilf here - thanks for all the comments.
Maybe I came off a little unclear, my point was not to infer that one is better than another, rather I was trying to explain some fundamental architectural differences between a Windows OS and a Linux OS - the separation of the X server, window manager and
OS is one of the key examples of this difference. There are pros and cons with these implementations of a graphical system (as well as to other graphical systems such as MacOS, and many others historically). It's largely dependent on what works best for
the problem you are trying to solve.
We think Windows provides a strong story here because there is a rich environment to develop against, with consistent and predictable support across a large amount of pcs and devices.
Keep your comments coming - also, check out the part II where we go into some further detail on the work in my lab. -Bill