Quote from: Doug Bissett on Today at 06:34:28 am
I don't use YUM,
That might be part of your problem.
No. I have the same problems on my systems that do use YUM, in fact, I could argue that I have worse problems on those systems. It appears that I am going to have to bite the bullet, and quit using one, or more, of my background programs, to free up more shared memory space. I am not sure what I am going to stop using, but something needs to be done about that problem, and using more DLLs is definitely not the answer.
The tool I use to manage libpath is inadequate. I have which.exe from the EMX days. It doesn't show the DLLs well enough. Is there a newer version of which?
Usage: which <command>...
which -d <dll>...
It's a simple, but good tool for finding things.
One of the problems with 'which' is that you need to remember to run it from the working directory of whatever you are trying to diagnose. It needs to follow the dot entry in LibPath, which is usually very near the beginning.
At the moment I am experimenting with using a directory directly off the root of the boot drive to hold all these extraneous DLLs that is listed in the libpath of config.sys. This works and because I back it up before any additions are made it is very easy to go back to what was working if anything breaks (I have had to do this a couple of times).
I think that I am going to start doing something like that, on one (test) system, then I will use RSYNC to keep all of my systems updated to what works on the test system (still no guarantee that updates won't cause problems, but...). I haven't tried that, yet, but I suspect that I will have to unlock all of the files to be able to update them, and a reboot may also be a good idea. If somebody has an available server, with RSYNC, everybody could update that way.
The biggest problem is to sort out which DLLs belong in a common system directory, and which ones belong in a program directory. Too many programs have been distributed with common system DLLs in their program directory, and that seems to be part of what is causing trouble. Those need to be removed, to avoid duplicates, and down level versions. Another problem is that some programs are distributed with down level files, which replace the later level files. That makes the "new" program work okay, but it can break something else. It also appears that none (or very few) of the ported DLLs have BLDLEVEL information in them, and that complicates the whole thing too.
not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
It has been said, that all you need is CUPS.DLL, somewhere in your LibPath. I can't vouch for that because I do have CUPS installed. There is also the problem where later versions of CUPS supply one of CUPS.DLL, CUPS17.DLL, or CUPS20.DLL. QPDFView (and some other programs) don't know about the last two. Of course, if you do put CUPS.DLL somewhere in your LibPath, then install CUPS later, you are exposed to having a problem, if you forget about that.
Then, there is the major problem of installing RPM/YUM, after you have updated things in other ways. YUM puts the path to what it installs first, which works okay, but it leaves behind the old stuff. Now, depending on what gets started first, you may have a down level version being used, which will break things that need the later version. This results in "sometimes it works, and sometimes it doesn't". Those problems can become extremely difficult to fix.
I will note one other thing, that I suspect few OS/2 users know anything about. Some of these ports are using the *NIX concept of "SYMLINKS". From what I understand, that allows the program to go looking for another program, which may not actually exist, but the program name has a method to run a different program in it's place. (Confused yet?). So you never know what you are really using, and that makes trouble shooting extremely difficult, especially when you look in the file of the first program, and find a path to the second program, rather than code. (Now, you should be totally confused). Somehow, I don't see this as being a good thing.
I will also mention the tool that is part of X(e)Workplace, called 'OS/2 Kernel'. Part of this tool will list your PATH statements (LibPath, Path, DPath), and determine if there are invalid paths. It also lists duplicate files found in the paths. Of course, it has the same problem as 'which' (mentioned above), because it cannot properly follow the dot entry in LibPath. One needs to be very careful when trying to analyze these things, and understand which file will be found first, under various circumstances.