Abstract: Described is installing multiple software packages to a computing device in a single transaction, whereby the multiple package installation commits if successful, or the device is rolled back to a determined state if unsuccessful. A client process provides a system service (installer) with a package, and the service partitions package installation actions into execution, commit and rollback phases, with the execution phase run for each package. If successful, the transaction is committed by performing the multiple commit phases. If unsuccessful, the installation is rolled back via the rollback phases. The phases may be interleaved, with execution and commit phases performed in FIFO order, and rollback phases performed in LIFO order. A client process may dynamically determine which packages to install, a client process may be embedded in a package and join the transaction, and/or one client process may delegate control to another client to add package actions to the transaction.

Abstract: An installation package associated with an application is obtained. Installation of the application in a first type of system is analyzed based at least in part on the installation package. A first set of changes made to the first type of system resulting from installation of the application in the first type of system is identified. Based on the first set of changes, a second set of changes made to a second type of system resulting from installation of the application in the second type of system is identified, and a recipe identifying the second set of changes is generated. A new installation package associated with the application can also be generated. This new installation package is configured for installation of the application on the second type of system, and is based at least in part on both the recipe and the installation package.

Abstract: An installation package associated with an application is obtained. Installation of the application in a first type of system is analyzed based at least in part on the installation package. A first set of changes made to the first type of system resulting from installation of the application in the first type of system is identified. Based on the first set of changes, a second set of changes made to a second type of system resulting from installation of the application in the second type of system is identified, and a recipe identifying the second set of changes is generated. A new installation package associated with the application can also be generated.

Abstract: Allowing a non-privileged user to apply a patch to a software product. A patch is received from a non-privileged user. It is determined if the received patch may be elevated by the non-privileged user for applying to a target software product. The received patch is applied to the target software product if it is determined that the received patch may be elevated by the non-privileged user for applying to the target software product.

Abstract: Uninstalling a patch applied to a software product installed on a computer. A current state of a software product is identified. A desired state of the software product is determined. The desired state of the software product represents a state of the software product when a patch applied to the software product is removed from the software product. The patch is removed from the software product to transition the software product from the identified current state to the determined desired state.

Abstract: Updating a software product by a plurality of patches. Sequencing data of each patch of the plurality of patches is received from a user such as a patch author. Each patch of the plurality of patches has a defined membership in a portion of the software product and has a defined order in the portion relative to one or more other patches that are members of the portion. The sequencing data indicates a portion of the software product of which the patch is a member and a relative ordering between the patch and one or more other members of the portion. A logical order of application for the plurality of patches is determined based on the received sequencing data. The plurality of patches is applied to the software product according to the determined logical order of application.

Abstract: Applying multiple patches to one or more software products. A plurality of patches is received from a user. A software product targeted by the received plurality of patches is determined. For the determined software product, one or more of the received plurality of patches that are applicable to the software product are identified. The identified one or more patches are applied to the software product as a function of a state of the software product in a single installation transaction.

Abstract: Described is installing multiple software packages to a computing device in a single transaction, whereby the multiple package installation commits if successful, or the device is rolled back to a determined state if unsuccessful. A client process provides a system service (installer) with a package, and the service partitions package installation actions into execution, commit and rollback phases, with the execution phase run for each package. If successful, the transaction is committed by performing the multiple commit phases. If unsuccessful, the installation is rolled back via the rollback phases. The phases may be interleaved, with execution and commit phases performed in FIFO order, and rollback phases performed in LIFO order. A client process may dynamically determine which packages to install, a client process may be embedded in a package and join the transaction, and/or one client process may delegate control to another client to add package actions to the transaction.

Abstract: Internal database validation is disclosed. In one embodiment, the system comprises a database having a data table and a validation table. The data table has at least one data column and at least one data row and the validation table has a plurality of validation columns and a validation row. Also included is a database engine module for maintaining the database and a database validation module operative to read a validation value from the validation column of the validation row and using the validation value to validate a data value in the data column of the data row.

Abstract: Internal database validation is disclosed. In one embodiment, the system comprises a database having a data table and a validation table. The data table has at least one data column and at least one data row and the validation table has a plurality of validation columns and a validation row. Also included is a database engine module for maintaining the database and a database validation module operative to read a validation value from the validation column of the validation row and using the validation value to validate a data value in the data column of the data row.

Abstract: Internal database validation system comprises a database having a data table and a validation table. The data table has at least one data column and at least one data row and the validation table has a plurality of validation columns and a validation row. Also included is a database engine module for maintaining the database and a database validation module operative to read a validation value from the validation column of the validation row and for using the validation value to validate a data value in the data column of the data row.