this weekend, a very kind eCS user informed me that there were a difference between standard
and yum/rpm based Warpin installers.
WarpIn is a native OS/2 (AKA eCS) programming package installer. RPM is a packaging method that YUM uses to install, and track, programming packages (which also includes DLLs). RPM and YUM are ported from the *NIX world. Each has it's own advantages, and disadvantages. Some discussion can be found in the OS2world forums.
I thought that OS/2 - eCS and NT were siblings so that any DLL linking/path problems experienced
on UNIX-based systems did not happen to us ?
More, or less, true, but each method has it's own advantages, and problems. The main problem, that we have today, is that those who are porting *NIX programs to run in OS/2 don't want to spend the time to find all of the places where *NIX type DLL linking is used in the programs, and convert them to OS/2 type linking, so they have decided to make a *NIX type of directory structure, with specific rules, to use with OS/2. That is essentially not compatible with the original OS/2 linking methods, but it does work, if you follow their rules. The result is what is known as "DLL HELL", if you break even one of the rules that the *NIX setup requires.
*NIX assumes that there is only ONE place, where all DLLs reside. By extension, that means that it is not possible to have more than one copy of any specific file name. That means that a user doesn't have to worry about down level, or duplicate, DLLs. One of the ways that *NIX updates such things, is by using RPM/YUM (although it seems that most distributions are moving on to something better). If you install RPM/YUM when you first install eCS, and NEVER use anything else to update, or install, anything, you will probably not have too much trouble. However, RPM/YUM does not install everything, so the user needs to use another method to install things. IF the user knows about the *NIX directory structure, and correctly uses that, they are likely to avoid most of the potential problems. Most OS/2 users have no idea what that is all about, so they almost always mess it up, and that will, eventually, cause trouble, especially if RPM/YUM is installed after the fact.
Some things that I have learned while testing the Arca Noae package installer (currently known as Yumie):
RPM and YUM work okay, when they work. It has been obvious that they do not always work properly. Yumie is only as good as YUM, and fixing problems with YUM can be a PITA.
An average user had better stick to the RPM release repository, or they are likely to have serious problems that can take some effort to figure out, and fix.
One "problem" with the release repository is that it can take MONTHS for new things to show up (also true of the experimental repository, but it is usually closer to being current).
Yumie is supposed to handle WarpIn packages, as well as RPM packages. So far, the WarpIn part is in early development. Far too much time has been required to try to work around YUM problems, so it hasn't been done yet.
The old RPM/YUM, installed by WarpIn, has a serious problem. Apparently, most users (including me), assumed that one should always use the YUM console to do updates. WRONG!. That uses a temporary sub set of YUM to get the current YUM package installed. The instructions do indicate that you can uninstall the WarpIn package, but it is not clear that you really should uninstall it (which also removes the YUM console). If you (correctly) use a normal command line to run YUM, it will work as well as it ever does. If you use the YUM console window, it will continue to use the old, temporary, installation, with down level software, and that causes problems. If you installed RPM/YUM with the eCS installer, it should work properly (but seems to break often).
Some things that you can do to prepare for the future:
Make sure that there is only ONE location where you keep "system" DLLs. By "system DLLs", i mean those that are used by more than one program (LIBC, GCC, and many others). This is complicated because eCS has added a new DLL directory where it keeps those things. When you add RPM/YUM, it makes another one, and takes no steps to remove duplicate (usually down level) DLLs from the old locations. Now, you have a problem if the wrong DLL gets used first, for any reason. The program that loads it will probably work, but if you then try to load a program that requires a later level, it isn't going to work (more likely, only one feature of the program won't work). If the later level DLL gets loaded first, both programs will work.
Look on your system for duplicate DLLs that may possibly get loaded. They don't necessarily need to be in LIBPATH. REMOVE them. Some programs were (incorrectly) packaged with DLLs, as a convenience to the user when they were distributed, and those do not get updated if they are not in the proper place. PTHREAD and MMAP are common.
Some users thought they were smart by moving "system" DLLs into "the only program that uses it" directory (Firefox, for instance). Now they installed a new program that uses one of those DLLs, and it won't work, so they finally figure out that it needs a DLL that is in Firefox. Their answer was to add Firefox to the LIBPATH. Then, they wonder why installing a new Firefox wiped out the DLL that wasn't supposed to be there in the first place.
Anyway, users should track those things down, and get rid of them. The complication is, that programs also use their own DLLs, which SHOULD be in the specific programs directory (and NOT in the single location used by "system" DLLs, although that should work okay).
You should also be aware, that QT programs store the location of the DLLs (and other things) in %HOME%\.config\Trolltech.ini. If anything in that file gets changed, you need to delete the file (it will be recreated). That is a common cause of QPDFView failing to find the PDF, DJVU, or PS, DLLs, even though they are where they should be found.
So, welcome to DLL HELL.