Beer28 wrote: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