Hello, thanks to minou for starting this discussion.
I want to make some clarifications.
What I see here (and everywhere else regarding this topic) is misunderstanding of the concepts. Despite everybody wants to think so, this problem has nothing to do with the religion. The whole question may be split up in two parts.
1. Reasons why developers want RPM.
2. Reasons why old-school users don't want RPM.
WHY DEVELOPERS WANT RPM
Ten years ago software was much simpler. A typical application would have one .EXE file and may be a couple of support .DLLs which often were pieces of external software this application depends upon. Other dependencies would include OS and Compiler runtime DLLs that were part of the OS itself and therefore were always installed on the user's computer. More over, these system dependencies were rather static as the system DLLs rarely changed in an incompatible way.
Nowadays the situation is completely different. Due to the fact that software becomes more and more specific as its complexity grows, a typical application now has a score of external dependencies which are *not* part of the OS installation. These dependencies also have their own dependencies, and each file needs to be of a particular version.
Because of the dramatically increased number of external dependencies and their stricter nature, the approach of packing each dependency with the application itself does not work any longer. Putting all hard disk space constrains aside, it creates a well-known DLL hell which, even if you manage to sort it out with hacks like LIBPATHSTRICT=T, eventually beats the whole purpose of a Dynamic Link Library which is intended to share the common parts of code among applications in order to save computer memory and other resources.
Making these external dependencies part of the OS itself (this is something eCS people have been trying to do) doesn't solve the problem because if we talk about modern software then we find that it is alive and changes over time. This means it is not static (as opposed to some ancient OS/2 system DLLs) and therefore it needs to be updated too. This just creates exactly the same problem as described above.
So the only thing the developer is left with here is to list all the dependencies in a README file, carefully describe all the steps necessary to install these dependencies and pray to god that the user has enough knowledge and experience to follow them. The more complex the software and the dependency list is, the higher is a chance that the user makes a tiny mistake that will lead to a completely broken installation, which is usually followed by blaming the developer for creating "such a crappy program" (with this statement being a completely false in 95% of all cases). Everybody is disappointed. For *no* reason.
All this created high demand in a program that would manage software installation on behalf of the end user and address the question of resolving the external dependencies in the first place as well as the task of configuring the installed software to create a proper environment that is expected by the developer for his software to work in.
RPM and YUM do just that. They are chosen simply because they turned out to be easier to port them to OS/2 than other similar tools. No religion here. No OS wars. It's like a saw for cutting wood when you realize that a knife doesn't work well any more.
WHY OLD-SCHOOL USERS DON'T WANT RPM
It's pretty clear, actually. From the days when the whole OS would fit on a 3.5' floppy disk, people used to be in charge of the entire system and its environment. They want to know what files the software puts on their hard disks, they want do decide which directory these files get written to. It all made sense back then, when the resources were very limited and the software was relatively simple so that the whole OS installation was manageable by a more or less experienced end user. Such manual control would let him optimize the system to best fit his needs and get the best out of the available hardware. It was very important.
In such situation, revoking this level of fine-grained control from hands of the end users is expectedly treated by them as the infringement on their freedom. And gives them all the mental pain it may cause.
However, today, due to the reasons described above and with the increased complexity of the software in the first place, the average end user has little to no knowledge what a particular piece of software needs and how it should be installed to work as designed. Which means, responding to the common "I want to install software where I want it to go" argument, that this argument is no longer valid. The developer of the software knows it much better.
There is no offense in this. And no limit on the freedom. You are still free to choose what software you want to install. This is where your individuality shows up. Developers offer you applications, you decide which ones serve you best and credit the respective authors. All the installation details are sorted out for you by specially designed tools. No reading installation instructions, no seeking for the right version of the dependent library, no even need to download anything by hand. And no need to care about future updates. Developers develop, users use. Everybody is happy.
I will give you another example. Consider you buy a car. If you are an average driver that needs the car to go from point A to point B, you will not complain that the engine is in front and you are not allowed to move it to the trunk. It is too complex for you to manage such things on your own and you probably have other things to do in your life that are much more important than taking care of your car's engine.
The modern software is just the same thing.
Of course, there are geeks over there that would disassemble their new cars and assemble them back putting everything the way they want. But hey, if you can do that, you will for sure be able to rip RPM off even if the whole eCS will come completely RPMized one day (it will). And especially for you we (the people who do Qt/Java/Odin/Unixports/etc.) will always provide ZIPs for all software we release as RPM. Just to make your life a bit easier. For the small but expected price -- you will have to sort out all dependencies and environment settings on your own. Which implies taking the risk of screwing up your system as well as recovering from such failures.
However, you should take into account that given the aforementioned complexity, it is impossible to describe every detail of the manual installation procedure and all possible pitfalls in the README. The multiply of the dependencies and environment parameters that the user is able to change on an eCS system gives us many hundreds of possible combinations and we are physically unable test them all. Even if we had a hundred of people in the test team (recall Windows). No need to mention that actually we have no (zero) paid testers.
All in all, our sole motivation to move to RPM is to increase the overall quality of the provided software by minimizing frequent problems that arise from incorrect installations and various conflicts with other software, as well as to simplify the task of managing software for those end users that don't want to be geeks in order to use their computers with the beloved operating system. Easy installation and update mechanisms also let us provide more frequent updates without disturbing end users too much which, again, means the increased software quality.
I hope this post helps you better understand the decision to move to RPM as well as the benefits it will give you as end users. If you have reasoned questions, feel free to ask. I will try to answer.
P.S. You may ask: we already have WarpIn. Why is it not enough? The answer: WarpIn is a great tool and it was a revolution in the OS/2 world in 90s, compared to these different application-specific installers we had (especially those ones from IBM). But WarpIn has some limitations which make it not sufficient for the modern software. These are its major limitations:
1. No way to perform an update that removes files.
2. Weak dependency handling, e.g. no notion of conflicts or alternatives.
3. No support to automatically download and install dependencies.
An attempt to add this to WarpIn is equivalent to re-writing it from scratch. We chose RPM instead of re-involving the wheel to save the resources and direct them to other useful tasks.
P.P.S. There is a section in the RPM/2 Wiki that shows you the basics of the YUM and RPM command line,
http://svn.netlabs.org/rpm/wiki/RpmHowToEndUsers. Just to demonstrate you how easy it is to install software with these tools even in the absense of the GUI front-end (which is another frequently used argument against RPM). No need to say that a GUI front-end for YUM and RPM is in our roadmap and those who attended at WSE'2011 could even see an early prototype.
P.P.P.S. The File and Directory Standard is a slightly different topic and it is not strictly connected with RPM. (Though it is connected with the question of creating an easily manageable complex system for which a tool like RPM is one of the requirements and a clearly defined FDS is another one).