When I mention a RPM screwing up your system, I mean an RPM messing up the packaging system. Like a partially installed RPM that fond a little bug that makes it abort,...
Well, all I can say is that any program may have bugs, and RPM is no exception. Presumably, you've reported any bugs you've found and they've been fixed.
I don't have enough experience with periphery RPM tools to provide any suggestions for dealing with a corrupt RPM database.
And how do I, after installing with "make install" say the new GTK libraries, then without forcing it installation install Gimp?
Not having installed either of these packages, I can only assume you mean, "...then without forcing it... install Gimp [from the RPM]?" Well, you can't install Gimp from the RPM without forcing it (using rpm --nodeps) because RPM, by the very nature of a package manager, is attempting to prevent you from inadvertently installing something without its prerequisites. RPM doesn't presume to guess about what it doesn't know. It doesn't know you have gtk installed because you didn't install it with RPM (and thus, the information isn't in the RPM database).
Debian was hardly the first operating system to include a package management system. Don't go attributing something to Debian that isn't theirs to claim.
Unless the LSB covers installation and package management utilities, there will always be significant distribution-specific elements of any Linux certification course. The RHCE course attempts to focus on the Red Hat-specific elements of Red Hat Linux. It is not an introduction to Linux course.
Also note that the Red Hat certification courses are still very new, and are being actively refined. Perhaps Red Hat will be offering a more general, more basic Linux course in the future, but right now, VARs and OEMs want to know the specifics of Red Hat Linux. (For what I would think are obvious reasons, Caldera users aren't pounding on Red Hat's doors asking for Caldera certification courses. Ditto for Debian and SuSE users.)
Red Hat does contribute to the LSB, but that doesn't mean RHS has to wait for the LSB to produce a final product before releasing its own product. No other distribution does, why should Red Hat? When the LSB has something concrete, that the project participants have agreed to, Red Hat will make an effort to adhere to it. Until this, Red Hat will continue to do what it thinks best, just like every other major distribution.
RPMS are great as long as you can trust them not to screw up your system.
The same can be said of any packaging system. The same can be said for any executable. The RPM format doesn't mean that the software is safe to use, just that it's easy to install on an RPM-based system. As with any technology, you have to apply some common sense.
Some incomplete RPMS when removed can (yes do) make life a living hell for any future version of that program.
That's not an RPM problem, it's a packaging problem. If the packager includes a buggy postinstall script, that script may cause problems, but that's not RPM's fault.
But then making your own RPM is more hassle than "make install".
Not if you have to maintain more than a small handful of systems. Any packaging system is better than "make install" when you've got a substantial number of systems to manage.
But if you ever install something that isn't an RPM then you can never install (AFAIK) without forcing it, a program that is dependant on it.
Slashdot Mirror
I don't have enough experience with periphery RPM tools to provide any suggestions for dealing with a corrupt RPM database.
Not having installed either of these packages, I can only assume you mean, "...then without forcing itDebian was hardly the first operating system to include a package management system. Don't go attributing something to Debian that isn't theirs to claim.
Also note that the Red Hat certification courses are still very new, and are being actively refined. Perhaps Red Hat will be offering a more general, more basic Linux course in the future, but right now, VARs and OEMs want to know the specifics of Red Hat Linux. (For what I would think are obvious reasons, Caldera users aren't pounding on Red Hat's doors asking for Caldera certification courses. Ditto for Debian and SuSE users.)
Red Hat does contribute to the LSB, but that doesn't mean RHS has to wait for the LSB to produce a final product before releasing its own product. No other distribution does, why should Red Hat? When the LSB has something concrete, that the project participants have agreed to, Red Hat will make an effort to adhere to it. Until this, Red Hat will continue to do what it thinks best, just like every other major distribution.