Dariusz, I have failed to grasp the central point of your post, but here follows some of the misconceptions in it.
...OK, here it is: given the age of OS/2 and for how long there has NOT been a real enterprise type update system available (think Fixpaks, etc) there are far too many combinations of working systems, or perhaps 99.9% working systems to expect that a single RPM/YUM based deployment methodolgy is going to work. Since I readily acknowledge and accept the small OS/2 development team limitations I am perfect happy and willing to unpack the recommended RPM archives since I am currently in the non-RPM/YUM camp...and you would do us all a favour by NOT pretending like RPM/YUM is the only NORMAL/ACCEPTABLE way to go about installing applications.
If you do not wish to help with these issues, do NOT help...but please, do not belittle folks for apparently horrific system configurations they have...tell me, are you running a multi-core setup, did you try SMP before deploying ACPI.PSD solution, do you know how the SMP mode impacts memory utilization and can you tell me what is so horribly misconfigured on my machine that my 6-core box simply will not nicely boot up? Does it have anything to do with mulit-disk and a large HPFS386 cache configuration? Do you really think there is a RPM/YUM solution for that too???
My DLL tracker is sometimes useful, but a bad, dirty hack, not a silver bullet.
Quite frankly, your DLL tracker is a great tool...I only wish that it was more prominently "published" and/or showcased as part of releases like Firefox...because it has the potential to help that part of our community who needs it.
Dude, do you really even read the issue tickets?
Each and every day...I'm on the FF mailing list, so yeah, sometimes tens of emails a day, I read them all...because maybe one of them may have something to do with an issue I have seen, or perhaps I can help someone on there by providing positive feedback as I first attempt to understand their challenge.
Here is an example, why is JoopN having such a strange issue with downloads??? Maybe libc DLL problem...but it sure looks like he worked through that and yet the problem persists...what now??? Are you going to write that off as a RPM/YUM problem as well, regardless of what is the actual root cause???
What about the 100% CPU utilization symptom? I've seen that for quite some time now...happens regularly here when I do not run with SET NSPR_OS2_NO_HIRES_TIMER=1 option...there was a pretty extensive debug session once, I had logged a ticket on the 24.x release for this (as well as other issues)...is that a RPM/YUM issue too???
Here is a better one: take the official stdcpp6.dll RPM release file (libstdc++6-4.9.2.1-3.oc00.i386.rpm), the recently created moz_required_dlls_v1.03.zip has a different DLL in it altogether. Which one to use now?
libstdc++6-4.9.2.1-3.oc00.i386.rpm => 02/02/2015, 410187 bytes
moz_required_dlls_v1.03.zip => 01/02/2015 14:08, 388453 bytes
So...the point being again: be helpful and therefore productive in your help, merely saying that someone is incapable of configuring their system because they are seeing a problem/symptom you do not see on your machine is very much quite the opposite of helping!