OS/2's human package manager
Why does OS/2 rely on a human package manager?
Is this really meant still seriously?
To support Andreas' case, he has one, OS/2 doesn't rely on a human package manager. Operations do. It may be hard for an engineer to understand that their Usenet trolls have to manage more than one system, while trying to avoid the DLL hell of DLLs like JPEG.DLL and Z.DLL.
Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you. That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products. If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of
different products for
different countries.
Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.
So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".
Hence: FF + OS/2 (and FF for eCS 1.x) = missing DLLs + missing requirements + missing support
So you're on your own then. While you're on your own, you may as well become the human package manager if the environment isn't that simple. It's easy to install an approved DLL. It's harder to uninstal the possibly destructive output of the random update policies of some random digital package manager, which works fine for "the average home user of selected products".
In the case of older hardware, the capacity of harddisks plays a role too. I'm pretty sure that a package manager isn't that aware of likely disk full-errors. If there's no eCS 1.x, eCs 2.x nor ArcaOS in the right language, then newer hardware isn't an obvious solution.
That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.
If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.
In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.
So please try to keep anyl Y2K-proof version of OS/2 Warp, settings of WPS objects and continuity of operations in mind while advocating that "one solution" (of some products) is "the solution" (of all products, languages and/or situations). Releasing qualifying updates for all OS/2-based products would help, but that won't solve all possible issues. If a new component really has to be added to ArcaOS, like a font, Unix directory structures or a package manager, then please consider releasing such a product as an update for all OS/2-based products. By default a simple install of OS/2 Warp 4 has no Unix directory structure, package manager, and so on.
So there's no such thing as a working "FF for OS/2", regardless of perfect and impressive OS/2 binaries. Install and update OS/2, install the FF package, and it won't work. The README.OS2 will result in a SYS1041 error.
OS/2 Warp (no FP for all OS languages), eCS 1.x (a few languages), eCS 2.x (fewer languages) and ArcaOS (EN only) are different products, each leaving a part of the community behind. In the case of ArcaOS EN perhaps a part of the German community too, slowly. The one and only package manager is a solution for the happy few. I guess availablity of ANPM is excellent, but that doesn't imply that everyone is willing to allow a random digital package manager, with random update policies, without detecting all possible OS/2 setups, to manage their packages.
Regarding applications, the number of quickly ported "OS/2" application which assume some eCS 2.x or ArcaOS setup is increasing. There is no "eCS 2.x setup for OS2" package, if you'd want such an environment in the first place. Or need such an environment. Often you can copy all files to one directory and keep the bootdrive clean, but not always. If not, then the required environment should have an added value for OS/2. Often it has no added value at all.
Of course the irrelevant, perfectly fine product WarpIN isn't the answer. A disadvantage of a (anything but perfect) WPI version of the FF products is that you may have to backup both the large WPI file and the large installed files. And, of course, WarpIN is a kind of package manager with its own policies. Here the human package manager typically extracts and converts the (sometimes anything but perfect) WarpIN install scripts to Rexx install scripts. If the results are identical, then managing and backing up the small Rexx install scripts is prefered above having to backup the whole original archive too. Fonts are a common exception (bootdrive files without a backup of the installed files, INSTFONT).
IIRC the game QNetwalk is an example of a Unixified app. It's improved significantly, but it uses a Unix directory structure. I guess just because Unix-based tools were used. Without any added value compared to an OS/2 or eCS 1.x x:\OS2GAMES\QNETWALK setup.