LPMtool's package processing algorithms use a generic resource-based model. It offers a number of improvements over the limited RPM based approach.

RPM's logic in selecting packages for upgrading is driven strictly by comparing the names and versions of individual packages. LPMtool's approach is more generic. For example, it is possible to specify that the given LPMtool package will upgrade any other package which installs a specific file, or a resource. The name of the other package does not matter. Neither does it matter what is defined architecture of either package. With RPM, a number of historical difficulties have been documented when an attempt was made to change the architecture of an existing RPM package. Inevitably, in each case it became necessary to change the package's name in order for RPM's upgrade logic to work correctly.

When issuing a new release of a system distribution, every package's internal version must be incremented. This is again because of RPM's simple version comparison-based logic. Unless every package in the new release carries a later version than the package in the old release, RPM wouldn't know that it needs to be upgraded.

LPMtool does not suffer from this limitation. Of course, all packages will probably still need rebuilding, to use the newer versions of interdependent libraries. But, it is not necessary to bump the package versions, LPMtool will upgrade the packages anyway. LPMtool will even upgrade to an older version of the package, if it's in the new system distribution.

A final example of LPMtool's very flexible resource-based model is the Linux kernel package. RPM can only process packages that contain the Linux kernel in “install” mode. Processing a kernel package in “upgrade” model will cause problems. Upgrading an RPM's package always removes the older version of the package, and removing the package containing the currently running Linux kernel will obviously be very problematic!

Therefore, RPM packages of the Linux kernel always demand special handling. No special handling is required in LPMtool's case. It is possible to specify the resources of an LPMtool's Linux kernel package so that both the install and upgrade operation are essentially equivalent, and “upgrading” to a new version of the Linux kernel does not remove the currently running kernel's package.