An adaptive iterative software package replacement method

Abstract

The present invention relates to the field of system migration and proposes an adaptive iterative software package replacement method, comprising: configuring a target software package repository according to a target operating system; executing a replacement instruction on a local software package set to generate a preliminary software package replacement set; initializing a historical problem software package list and a current problem software package list to empty lists; performing a replacement on the current software package replacement set; if the replacement is successful, the current software package replacement set is correct; if the replacement fails, identifying the current problem software package; adding the identified problem software package to the current problem software package list; determining whether the current problem software package list and the historical problem software package list are identical; if so, the software package replacement fails; if not, adding the identified problem software package to the historical problem software package list; iteratively optimizing the software package replacement set and re-performing software package replacement. The above-mentioned solution solves the problem of operating system migration failure caused by software package conflicts.

Description

Technical Field

[0001] The present invention relates to the field of system migration, and in particular provides a self-adaptive iterative software package replacement method. Background Art

[0002] CentOS systems have been discontinued one after another. To address numerous security risks, various operating system vendors have proposed operating system migration, that is, to smoothly migrate the existing CentOS systems in the market to domestic operating systems. The migration plan for existing operating systems (especially CentOS 6 and 7 series, etc.) mainly uses YUM for batch software package replacement. YUM is a package manager based on RPM package management that is widely used in Linux operating system distributions such as Red Hat and CentOS.

[0003] However, existing package managers often fail to perform batch package replacement tasks due to missing package dependencies, conflicting versions, and abnormal execution of package transactions. In these scenarios, existing solutions rely solely on manual troubleshooting, which is inefficient and prone to errors. Furthermore, in operating system migration scenarios, batch package replacement tasks require even higher stability to ensure business continuity; failure can cause immeasurable losses.

[0004] For these reasons, existing OS migration solutions cannot automatically generate the correct set of replacement packages due to limitations in package replacement technology, leading to migration failures. Specifically, migration failures can occur when the OS or target repository has the following issues:

[0005] (1) Missing software package dependencies

[0006] During the OS migration process, if the target repository software package to be installed lacks installation dependencies, existing package replacement technology cannot automatically skip the missing packages, causing the entire batch task to fail and the OS migration to fail.

[0007] (2) The target repository contains multiple versions of software packages

[0008] During the OS migration process, if multiple versions of a software package exist in the target repository, the package manager will automatically search for and install the highest version. However, if the highest version doesn't satisfy dependencies, existing package replacement technology won't automatically search for other packages that satisfy the dependencies. Instead, it will report an error, causing the entire batch task to fail and the OS migration to fail.

[0009] (3) Software package transaction execution exception

[0010] During the operating system migration process, if there is a file conflict between the software package in the target repository and the local software package, the existing package replacement technology will not automatically skip the software package with the file conflict. Instead, it will report an error during the software package transaction execution phase, causing the entire batch task to fail and the operating system migration to fail.

[0011] Accordingly, the art needs a new software package replacement solution to solve the above problems. Summary of the Invention

[0012] In order to overcome the above-mentioned defects, the present invention is proposed, which can automatically generate a correct software package replacement set and solve the problem of operating system migration failure caused by software package conflicts.

[0013] The present invention provides an adaptive iterative software package replacement method, comprising the following steps:

[0014] S1: Back up the repo file of the original operating system and configure the target software package repository according to the target operating system;

[0015] S2: Use the package manager to execute the replacement command on the local package set, replacing it with the highest version of the package in the target package repository by default, and generate a preliminary package replacement set;

[0016] S3: Initialize the historical problem software package list to an empty list, wherein the historical problem software package list is used to store all problem software packages identified after a historical software package replacement fails;

[0017] S4: Initialize the current round problem software package list to an empty list, wherein the current round problem software package list is used to store the current round problem software packages and historical problem software packages;

[0018] S5: Use the package manager to perform a replacement on the current package replacement set;

[0019] S6: Determine whether the replacement is successful based on the return code of the software package manager. If the replacement is successful, the current software package replacement set is correct, the operating system migration is successful, and the migration process is exited. If the replacement fails, execute step S7;

[0020] S7: Identify the problem software package for this round;

[0021] S8: Add the identified problematic software package to the list of problematic software packages in this round;

[0022] S9: Determine whether the current round of problem software package lists and the historical problem software package lists are the same. If they are, the current round of software package replacement has failed, and no new problem software package has been identified. The adaptive iterative software package replacement has failed, the operating system migration has failed, and the migration process is exited. If they are different, the current round of software package replacement has failed, but a new problem software package has been identified, and step S10 is executed.

[0023] S10: adding the identified new problematic software package to the historical problematic software package list for comparison with the next round's problematic software package list;

[0024] S11: In the current software package replacement set, exclude the list of historical problem software packages, iteratively optimize the software package replacement set, and return to step S5 to perform software package replacement.

[0025] Furthermore, when the YUM package manager is used, identifying the problematic software package in this round includes the following steps:

[0026] During the transaction build phase, package dependencies are parsed and transaction sets are packaged. Without installing the packages, issues like missing package dependencies and conflicts between multiple versions of packages may occur.

[0027] During the transaction execution phase, which includes software package downloading, software package checking, and software package transaction testing, software package transaction execution exceptions may occur.

[0028] Furthermore, in the YUM package manager, the software package with the missing package dependency problem is obtained through a package instance with unavailable dependencies, which stores the package name, version and architecture information of the problem software package, and the software package corresponding to the instance is identified as the problem software package.

[0029] Furthermore, in the YUM package manager, the software package with the multi-version conflict problem is obtained through reqTup, where reqTup represents the name, flag and version of the package required to meet the dependency. All packages in the target repository that do not meet reqTup are traversed and identified as problem software packages.

[0030] Furthermore, in the YUM software package manager, the software package with the software package transaction execution exception problem is obtained through tserrors, where tserrors represents a problem description of the software package execution transaction set, and the obtained software package is identified as a problem software package.

[0031] Working principle and beneficial effects of the present invention:

[0032] In the technical solution implemented in the present invention, before using a package manager to replace the current package replacement set, a list of historical problem packages and a list of current problem packages are initialized. If a package replacement fails, the problem package is identified and added to the current problem package list. The list is then compared with the historical problem package list. If the two lists are identical, the replacement fails. If they are different, the problem package is added to the historical problem package list. The historical problem package list is then removed from the current package replacement set, and the package replacement set is iteratively optimized. This invention automatically generates a correct package replacement set during the batch replacement phase of an operating system, resolving the migration failure issue caused by package replacement anomalies during existing operating system migrations. This significantly improves the stability of operating system migrations and reduces manual processing costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The disclosure of the present invention will be more easily understood with reference to the accompanying drawings. Those skilled in the art will readily appreciate that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Furthermore, similar numbers in the drawings represent similar components, wherein:

[0034] Figure 1 The figure is a flow chart of the main steps of an adaptive iterative software package replacement method of the present invention. DETAILED DESCRIPTION

[0035] Some embodiments of the present invention are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0036] In existing operating system migration solutions, tasks such as issuing migration requests and reporting migration results are all part of task management; operating system migration assessment and operating system migration compatibility analysis also fall within the scope of assessment, and none of them involve modifications to the migrated system itself.

[0037] However, batch software package replacement is the most critical phase in an OS migration, as it involves replacing the kernel, system services, system tools, and utilities, essentially modifying the OS. Therefore, the stability of the OS migration task depends entirely on the stability of the batch software package replacement.

[0038] Figure 1 This is a flow chart of the main steps of an adaptive iterative software package replacement method of the present invention. Figure 1 As shown, an adaptive iterative software package replacement method in this embodiment mainly includes the following steps S1 to S11.

[0039] S1: Target software package repository configuration

[0040] After the operating system migration begins, first back up the repo files of the original operating system, then configure the target software package repository according to the target operating system and prepare for batch software package replacement.

[0041] S2: Generate a preliminary set of package replacements

[0042] After the target repository is configured, batch package replacement begins. First, the package manager executes the replacement command on the local package set (that is, the package set installed in the environment). A preliminary package replacement set is automatically generated based on the package manager's default rules (that is, the highest version of the package in the target repository is replaced by the default version).

[0043] In this embodiment, the preliminary replacement set of packages generated is not necessarily the correct set and requires further optimization. This is because it may encounter issues such as missing dependencies and file conflicts during the replacement process, potentially causing replacement failure. After the preliminary replacement set is generated, it will be continuously optimized using adaptive iterative package replacement technology.

[0044] S3: Initialize the list of historical problem packages

[0045] The historical problem package list is initialized to an empty list. The historical problem package list is used to store all problem packages identified after the historical package replacement fails. Since there were no problem packages before the first round of package replacement, the list is initialized to an empty list.

[0046] S4: Initialize the list of problem packages for this round

[0047] Initialize the current round's problem package list to an empty list. This round's problem package list is used to store this round's problem packages and historical problem packages. Because there were no problem packages before the first round of package replacement, the list is initialized to an empty list.

[0048] S5: Perform package replacement

[0049] The software package manager is used to perform a replacement on the current software package replacement set (when step S5 is performed for the first time, the current software package replacement set is the preliminary software package replacement set).

[0050] S6: Determine whether the software package is replaced successfully

[0051] After the package replacement is complete, determine whether the replacement was successful based on the package manager's return code (generally, a return code of 0 indicates a successful replacement). If the replacement is successful, the current package replacement set is correct, the operating system migration is successful, and the migration process exits. If the replacement fails, identify the problematic package.

[0052] S7: Identify Problem Software Package

[0053] After a software package replacement fails, this phase begins to identify the problematic software package.

[0054] In one embodiment, taking the YUM package manager as an example, the method for identifying the problematic software package is as follows:

[0055] In YUM, you can identify problem packages based on the stage at which package conflicts occur;

[0056] For example, during the build phase, package dependencies are parsed and the transaction set is packaged, but the package installation is not performed. This can lead to missing package dependencies and conflicts between multiple versions of the package.

[0057] For example, during the transaction execution phase, including software package downloading, software package checking, and software package transaction testing, problems such as abnormal software package transaction execution, such as file conflicts, may occur during this phase.

[0058] The specific problem description and identification method are as follows:

[0059] (1) Missing software package dependencies

[0060] Missing package dependencies means that the target repository's packages lack installation dependencies, resulting in installation failure and batch package replacement failure.

[0061] In YUM, the software package with missing dependencies can be obtained through reqPo (a package instance with unavailable dependencies). This instance stores information such as the package name, version, and architecture of the problem software package, and the software package corresponding to the reqPo instance is identified as the problem software package.

[0062] (2) Software package multi-version conflicts

[0063] A package multi-version conflict occurs when multiple versions of a package exist in the target repository. The package manager automatically searches for and installs the highest version. However, if the highest version doesn't satisfy dependencies, existing package replacement technology doesn't automatically search for other packages that satisfy the dependencies. Instead, it reports an error, causing batch package replacement to fail.

[0064] In YUM, packages with multiple conflicting versions can be obtained through reqTup (the name, flag, and version of the package required to satisfy the dependency). All versions of the package in the target repository are traversed. If a version does not meet the description of reqTup, it is proved that this version should not be installed and is identified as a problem package.

[0065] (3) Software package transaction execution exception

[0066] Software package transaction execution exception means that if there is a file conflict between the software package in the target repository and the local software package, the existing software package replacement technology will not automatically skip the software package with the file conflict, causing the batch software package replacement to fail.

[0067] In YUM, software packages with abnormal package transaction execution can be obtained through tserrors (problem descriptions in the package execution transaction set, such as package file conflicts), and the obtained software packages are identified as problem software packages.

[0068] In another embodiment, when the user uses a DNF software package manager, the problem software package may be identified by performing string matching on the problem description. This embodiment is not limited to the specific software package manager used by the system.

[0069] S8: Add to the list of problem packages for this round

[0070] After the problem software package is identified, it is added to the problem software package list of this round. This list is a global shared variable that ensures that all problem software packages are added to the variable. Generally, this global shared variable is implemented through the singleton pattern to ensure the uniqueness of the global shared variable in multiple rounds of software package replacement.

[0071] S9: Determine whether a new problematic software package is identified

[0072] After adding the problematic packages identified in this round to the problematic package list, check whether the problematic package list in this round matches the historical problematic package list. If they match, the package replacement in this round failed and no new problematic packages were identified. The adaptive iterative package replacement process failed, the operating system migration failed, and the migration process aborted. If they differ, the package replacement in this round failed, but new problematic packages were identified.

[0073] S10: Add to the list of historical problem packages

[0074] After a new problem package is identified, it is added to the historical problem package list for comparison with the current problem package list of the next round to determine whether a new problem package is identified in the next round.

[0075] S11: Iteratively optimize the package replacement set

[0076] In the current software package replacement set, the list of historical problem software packages is excluded, the software package replacement set is iteratively optimized, and step S5 is re-entered to perform software package replacement.

[0077] Based on steps S1-S11 above, the adaptive iterative package replacement method proposed in this invention performs multiple rounds of a package replacement task, identifying problematic packages after each replacement round and iteratively optimizing the replacement package set until a correct replacement package set (i.e., one that will not cause migration failure) is generated. This method addresses operating system migration failures caused by missing package dependencies, conflicting versions of multiple packages, and abnormal execution of package transactions. In particular, in step S7, this embodiment allows for manual adjustment of the problematic package identification strategy based on different package managers, while remaining unchanged in the remaining stages, facilitating scalability.

[0078] This embodiment can automatically generate a correct software package replacement set during the batch replacement phase of the operating system software package, solving the migration failure problem caused by abnormal software package replacement during the existing operating system migration, greatly improving the stability of the operating system migration, and reducing manual processing costs.

[0079] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0080] Thus far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art may make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will fall within the scope of protection of the present invention.

Claims

1. An adaptive iterative software package replacement method, characterized in that: The following steps are involved: S1: Back up the repo file of the original operating system and configure the target software package repository according to the target operating system; S2: Use the package manager to execute the replacement command on the local package set, replacing it with the highest version of the package in the target package repository by default, and generate a preliminary package replacement set; S3: Initialize the historical problem software package list to an empty list, wherein the historical problem software package list is used to store all problem software packages identified after a historical software package replacement fails; S4: Initialize the current round problem software package list to an empty list, wherein the current round problem software package list is used to store the current round problem software packages and historical problem software packages; S5: Use the package manager to perform a replacement on the current package replacement set; S6: Determine whether the replacement is successful based on the return code of the software package manager. If the replacement is successful, the current software package replacement set is correct, the operating system migration is successful, and the migration process is exited. If the replacement fails, execute step S7; S7: Identify the problem software package for this round; S8: Add the identified problematic software package to the list of problematic software packages in this round; S9: Determine whether the current round's problem software package list is the same as the historical problem software package list. If they are, the current round's software package replacement fails. No new problem software package is identified, the adaptive iterative software package replacement fails, the operating system migration fails, and the migration process exits. If they are different, the current round of software package replacement fails, but a new problematic software package is identified, and step S10 is executed; S10: adding the identified new problematic software package to the historical problematic software package list for comparison with the next round's problematic software package list; S11: In the current software package replacement set, exclude the list of historical problem software packages, iteratively optimize the software package replacement set, and return to step S5 to perform software package replacement.

2. The adaptive iterative software package replacement method according to claim 1, characterized in that: When using the YUM package manager, identifying the problematic packages in this round includes the following steps: During the transaction build phase, package dependencies are parsed and transaction sets are packaged. Without installing the packages, issues like missing package dependencies and conflicts between multiple versions of packages may occur. During the transaction execution phase, which includes software package downloading, software package checking, and software package transaction testing, software package transaction execution exceptions may occur.

3. The adaptive iterative software package replacement method according to claim 2, characterized in that: In the YUM package manager, the software package with the missing package dependency problem is obtained through a package instance with unavailable dependencies. The instance stores the package name, version, and architecture information of the problematic software package, and the software package corresponding to the instance is identified as the problematic software package.

4. The adaptive iterative software package replacement method according to claim 2, characterized in that: In the YUM package manager, the software package with the multi-version conflict problem is obtained through reqTup, which represents the name, flag and version of the package required to meet the dependency. All packages in the target repository that do not meet reqTup are traversed and identified as problem software packages.

5. The adaptive iterative software package replacement method according to claim 2, characterized in that: In the YUM package manager, the software package with the abnormal software package transaction execution problem is obtained through tserrors, where tserrors represents a problem description in the software package execution transaction set, and the obtained software package is identified as a problem software package.

Images