The problem with using a database that only has 2 levels to track installed products (like WarpIn) is if the product has lots of components the "application" is listed multiple times with different "keys" in order to list the different components or subsystems. If you want to deinstall the product you have to deinstall each of the application-key pairs. To use an example: Doodle's Screen Saver is listed as an application 29 times (on my machine) in WarpIn's database. So to deinstall one has to right-click 29 times on the application and select deinstall.
That is true. Back when WarpIn was developed, it was unusual to have more than one component. Three, at the most, so it wasn't much of a problem. If you want an example of a complicated WarpIn installer, have a look at the GENMAC installer. One of the "problems" with WarpIn, is that it is very flexible, and can easily be augmented using REXX. Lots of people have invented ways to use that, and sometimes it can cause problems.
You can select more than one package, using the standard selection methods. If it was packaged in a way that keeps all of the parts together, that is pretty easy. To use DSS as an example, click the first entry, move to the last entry and Shift click. They will all be selected, and you can RMB to uninstall them all. I suspect that it would be far more work, than can be justified, to change that, and it would probably break a lot of things that work now.
But the issue is why should I have to? When the better way is to simply give the user the choice on where to install a product when using APM/YUM/RPM.
You do have the choice. Very few things must be on the boot volume. Back when DOS, and WinOS2, support was created, a 10 MB (yeah, "MB") hard disk was HUGE. The disk size did not become a problem until disk larger than 2 GB became available. IBM never fixed the problem, so somebody developed 2GBfix to avoid the problem (there are a couple of others, but 2GBfix works best). If you don't want to use that, it is your choice. Probably the best approach is to have a small partition dedicated to DOS/WinOS2 programs. That could be the C: drive, if you make your boot drive something other than C:. Another way to avoid using space on the boot drive, is to put the RPM/YUM stuff on a different drive.
When the better way is to simply give the user the choice on where to install a product when using APM/YUM/RPM.
Using WarpIn, you can select where to put things, but it usually doesn't make sense to do that. The default locations (as defined in the WarpIn settings, which I usually change, to my own preferences, at OS install time), are usually best. I assume you meant ANPM, not APM (a power manager) with RPM/YUM. You need to realize that RPM/YUM is designed to work with Linux, which usually has fixed (not selectable) locations for things. A lot of that was never changed, because it makes it easier to port programs from Linux. In fact, there are very few programs that actually get installed using RPM/YUM. Almost all of that stuff is support for Linux ports, which are often installed by WarpIn. There is a RPM package for Firefox, but I doubt if it will ever be pushed to the release channel, simply because Firefox is no longer being ported for OS/2. From what I hear, the new browser (Otter) will be an RPM package (probably with no other options for installing, because of the complexity involved).
I think Martin IS intending to distribute old style OS/2 apps that way. And I think it is an excellent idea if we can get some flexibility in the install process.
Old style OS/2 apps are not suited to distribution as RPM packages, and it would be a lot of work to do it, for little, or no, gain. Other things could use a little polish, and it would probably be easier to repackage the very old programs as WarpIn packages (many of them just need to place the files, and add an icon). RPM/YUM is useful when there are many *NIX requirements. It is not as useful when it is a stand alone program, but it should be possible to do it.
I am just trying to, politely, suggest that adding the ability to select a destination for a application when installing with APM/YUM/RPM would be a fantastic feature.
Perhaps so, but that would make it a LOT more difficult to port RPM and YUM (ANPM just uses some intelligence to run YUM). They are not designed to do things like that, and changing too many things tends to break other things. In fact, it is probably possible, if the the person building the package can find a way to do it. I understand that scripts are used to do some things, perhaps they can ask where to put things, when the package might actually work in non standard locations. The main "problem" is that doing things like that, makes supporting the whole thing a lot more complex, and one thing that we don't have, are a lot of support people to try to figure out what some user has done to themselves. It happens often enough when it is a supported configuration. The other problem is that some future change might make whatever was done fail to work. Then, who is going to figure that out? There just aren't enough people to do it all.