Dariusz,
Thank you for the detailed replies.
Well, basically I pulled the Bitworks published Firefox release which then required a number of RPM packages. I do not use RPM/YUM, I have been relying on ZIP releases mostly because it gives me control over what goes where and my setups are rather simple and I'm trying to keep it that way:
1) g:\os\dll
2) g:\usr\dll
3) g:\usr\bin
...I attempt to keep the duplicate DLLs to a minimum. Basically all non-IBM OS/2 dlls go to \usr\dll.
Ok, your intention is clear but know what: RPM does what you just listed for you for free and in a completely unattended (yet 100% predictable) way. It keeps all non-OS/2 things in one place, it rules out the duplicate problems as well as *all* dependencies, including the rather complex cases. (Yes, there are some edge cases where it fails with dependencies but these are rare and may be solved on the vendor's side when done properly — we are working on that). So I strongly recommend you to try YUM/RPM as I think it perfectly fits your scenario.
For whatever reason, I could not extract the needed DLLs out of the RPM packages (using ArchiveView and consistently getting "SYS1092: The handle could not be duplicated during a pipe operation.
" error), and so the minute that failed it was a dead-end...
This seems that the ArchView installation is broken on your side for whatever reason. I bet that this is because you did something wrong when manually managing your DLLs as I'm 100% sure that on a fresh eCS 2.2 Beta II install it will work soothly (my dev machine is close to the fresh install as much as possible — I isolate all dev work in separate .cmd environments).
While I understand the eventual simplicity of relying on RPM/YUM it just seems like we're not quite there yet. So in terms of testing out these beta release it just seems like it would be so much simpler to get a ZIP Firefox release and a matching ZIP release of all the required DLLs.
Maintaining such a ZIP is not a trivial task as it might seem and requires additional resources. Given that we invested a lot in RPM already to solve this particular task in a more perfect way, we are not going to do much in ZIP support. I hope you understand. I strongly recommend you to switch to YUM/RPM. We will better fix the RPM problems you discover rather than maintain such ZIPs (again, just because it's a more rational time investment).
Yeah, the "fly in the ointment" is the missing stuff, so just to show everyone else what I've got, here is the breakdown of what's available:
In our last README.OS2, we deliberately replaced all references to ZIP (that we auto-generate from RPMs for your convenience) in favor of RPM archives themselves for a very simple reason. In RPM, a project (application, library, etc) may be divided in several pieces: the application itself, the development files, the debug data etc. with each piece having its own RPM. When we create ZIPs we gather all project RPMs and pack them into a single ZIP. For some projects, the resulting ZIP may be very big. This the case for GCC, for instance: gcc-4_9_2_1-3_oc00.zip is 86 MB in size. It is insane to ask users to download this file if they only need a tiny DLL (gcc1.dll) which is only 30K. So we decided to change all ZIP link to direct RPM links. This assumes that you have a working ArcView installation, of course.
In cases of a single RPM per project, you were able to find the matching ZIP by hand. But in case of GCC you failed because there is simply no ZIP for this individual package we are referring to, you have to download the whole gcc-4_9_2_1-3_oc00.zip thingy. We may consider packing each RPM into a separate ZIP eventually but this is to be decided yet.
