Entry tags:
my packaging tool is better than your packaging tool
I have a longer rant on this subject elsewhere, incomplete, but here is a brief, concise note that may be of use in the interim:
if you tell RPM to install software, and you tell it to disregard any potential dependency problems or file-overwrite problems, and your system then breaks, RPM is not at fault. Furthermore, using this as "evidence" that RPM is broken, or less functional than $your_favourite_packaging_tool, will cause me to insert my boot into your anatomy at any convieniently obvious point and root around for a bit until you reconsider your opinion.In summary, don't be an idiot.

no subject
I would differ; to install something that's not already on the system, there shouldn't ever be a need to tell RPM to disregard any potential dependencies or file-overwrite problems. That's a design flaw, perhaps of the package itself, but certainly something that's facilitated by RPM.
no subject
Now, if you're going to post comments in my journal, particularly since I don't know you from Adam, please pay close attention to the last line of the original post. This may be a public journal, but it is my public journal, and I determine what the standards for idiocy here are. Please think carefully about your next post.
no subject
If one were to write a packaging tool that didn't allow some fool to build a package against some package that doesn't exist, and was equally as easy to use as RPM is, then that would be a better packaging tool. As a parallel example, take a C compiler, and a user who types int *i; printf("%s", &i);. Is the user at fault here? Yes, absolutely. Is the compiler better if it warns the user about what they've done? Yes, absolutely. Tools that make it harder for the user to be an idiot are better tools. (Cf. Perl requiring braces in all if statements--that annoyed me when I encountered it first, but then I realised how many people don't use cperl-mode or something like it for all the C-family languages, and as a result still have real problems with dangling elses.)
I've no real desire to argue about packaging systems in general. RPM isn't going to change any time soon--Red Hat have other, more pressing things to put their resources into, and the bleeding edge of package management is sufficiently far away from RPM that very few of the people who care deeply about these things are likely to put effort into it. But this aspect of it could have been done much better.