Self-adaptive iteration software package replacement method

Abstract

The invention relates to the field of system migration, and provides a self-adaptive iterative software package replacement method which comprises the following steps: configuring a target software package warehouse according to a target operating system; executing a replacement instruction on the local software package set to generate a preliminary software package replacement set; initializing a historical problem software package list and a current round of problem software package list to be empty lists; performing replacement on the current software package replacement set; if the replacement succeeds, the current software package replacement set is correct, and if the replacement fails, a problem software package of the round is identified; adding the identified problem software package into a problem software package list of the round; judging whether the problem software package list of the round is the same as the historical problem software package list or not, and if yes, determining that the software package replacement fails; if not, adding the identified problem software package into a historical problem software package list; and iteratively optimizing the software package replacement set, and carrying out software package replacement again. By means of the scheme, the problem that the operation system fails to migrate due to software package conflicts is solved.

Description

Technical Field

[0001] The present invention relates to the field of system migration, and specifically provides an adaptive iterative software package replacement method. Background Art

[0002] The CentOS system has successively stopped providing services. To address various security risks, each operating system manufacturer has proposed to migrate the operating system, that is, to smoothly migrate the existing CentOS systems in the market to domestic operating systems. The existing operating system (especially CentOS 6 series, 7 series, etc.) migration solutions mainly use YUM to perform batch software package replacement. YUM is a software package manager based on RPM package management that is widely used in Linux operating system distributions such as RedHat and CentOS.

[0003] However, when the existing software package manager performs batch software package replacement tasks, it often fails to process the tasks due to reasons such as missing software package dependencies, multi-version conflicts of software packages, and abnormal execution of software package transactions. In such scenarios, the existing solutions can only be manually checked and processed, which is inefficient and error-prone. In the scenario of operating system migration, to ensure the continuity of user services, the stability requirements for batch software package replacement tasks are higher. Once the task processing fails, it will cause incalculable losses.

[0004] For the above reasons, due to the limitations of software package replacement technology, the existing operating system migration solutions cannot automatically generate a correct software package replacement set, resulting in migration failures. Specifically, when the following problems exist in the operating system or the target repository, migration failures will occur: (1) Missing software package dependencies During the operating system migration process, if the target repository software package to be installed lacks installation dependencies, the existing software package replacement technology cannot automatically skip the software packages with missing dependencies, which will cause the entire batch task to fail and result in the failure of operating system migration; (2) There are multiple versions of software packages in the target repository During the operating system migration process, when there are multiple versions of software packages in the target repository, the software package manager will automatically search for and install the highest version of the software package. However, if the highest version of the software package does not meet the dependency relationship, the existing software package replacement technology will not automatically query other software packages that meet the dependency relationship, but will directly report an error, resulting in the failure of the entire batch task and the failure of operating system migration; (3) Abnormal execution of software package transactions During the operating system migration process, if there are file conflicts between the software packages in the target repository and the local software packages, the existing software package replacement technology will not automatically skip the software packages with file conflicts. Instead, it will report an error during the software package transaction execution phase, resulting in the failure of the entire batch task execution and the failure of the operating system migration.

[0005] Correspondingly, there is a need in the art for a new software package replacement solution to solve the above problems. Summary of the Invention

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

[0007] The present invention provides an adaptive iterative software package replacement method, including the following steps: 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 software package manager to execute the replacement instruction on the local software package set, default to replace with the highest version of the software package in the target software package repository, and generate a preliminary software package replacement set; S3: Initialize the historical problem software package list as an empty list, and the historical problem software package list is used to store all the problem software packages identified after the failure of historical software package replacement; S4: Initialize the current round of problem software package list as an empty list, and the current round of problem software package list is used to store the problem software packages of the current round and the historical problem software packages; S5: Use the software package manager to execute a replacement on the current software package replacement set; S6: Judge whether the replacement is successful according to the return code of the software package manager. If the replacement is successful, the current software package replacement set is correct and the operating system migration is successful, and the migration process is exited. If the replacement fails, execute step S7; S7: Identify the problem software packages of the current round; S8: Add the identified problem software packages to the current round of problem software package list; S9: Judge whether the current round of problem software package list is the same as the historical problem software package list. If they are the same, it means that the software package replacement of the current round fails and no new problem software packages are identified, then the adaptive iterative software package replacement fails and the operating system migration fails, and the migration process is exited; if they are different, it means that the software package replacement of the current round fails but new problem software packages are identified, and execute step S10; S10: Add the identified new problem software packages to the historical problem software package list for comparison with the current round of problem software package list in the next round; S11: In the current software package replacement set, exclude the historical problem software package list, iteratively optimize the software package replacement set, and return to step S5 for software package replacement.

[0008] Further, when using the YUM software package manager, the identification of the problem software packages in this round includes the following steps: In the stage of building the transaction, parse the software package dependencies and package the transaction set without installing the software packages. In this stage, problems such as missing software package dependencies and multi-version conflicts of software packages may occur. In the stage of executing the transaction, including software package download, software package check, and software package transaction test, problems such as abnormal execution of software package transactions may occur in this stage.

[0009] Further, in the YUM software package manager, the software packages with missing software package dependencies are obtained through the package instance with unfulfilled dependencies. This instance stores the package name, version, and architecture information of the problem software package, and the software package corresponding to this instance is identified as a problem software package.

[0010] Further, in the YUM software package manager, the software packages with multi-version conflicts of software packages are obtained through reqTup. The reqTup represents the name, flag, and version of the packages required to satisfy the dependencies. Traverse all the packages in the target repository that do not meet the reqTup and identify them as problem software packages.

[0011] Further, in the YUM software package manager, the software packages with abnormal software package transaction execution problems are obtained through tserrors. The tserrors represents the problem description in the software package execution transaction set, and the obtained software packages are identified as problem software packages.

[0012] The working principle and beneficial effects of the present invention: In implementing the technical solution of the present invention, before using the software package manager to perform replacement on the current software package replacement set, initialize the historical problem software package list and the problem software package list in this round. After the software package replacement fails, identify the problem software packages, add the identified problem software packages to the problem software package list in this round, and compare them with the historical problem software package list. If they are the same, the replacement fails; if they are different, add the problem software packages to the historical problem software package list, exclude the historical problem software package list from the current software package replacement set, and iteratively optimize the software package replacement set. The present invention can automatically generate a correct software package replacement set in the stage of batch replacement of software packages in the operating system, solve the problem of migration failure caused by abnormal software package replacement during the migration of the existing operating system, greatly improve the stability of the operating system migration, and reduce the manual processing cost. Description of the Drawings

[0013] Referring to the accompanying drawings, the disclosure of the present invention will become more readily understandable. It is readily understandable to those skilled in the art that these drawings are merely for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, where: Figure 1 is a schematic diagram of the main steps of an adaptive iterative software package replacement method of the present invention. Specific embodiments

[0014] The following describes some embodiments of the present invention with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely for explaining the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0015] 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 evaluation, operating system migration compatibility analysis, etc. also belong to the evaluation category, and none of them modify the system being migrated itself.

[0016] However, batch software package replacement is the most important stage in operating system migration because this stage will perform a series of replacements on the system kernel, system services, system tools, and utilities, etc., which is a substantial modification to the operating system. Therefore, the stability of the operating system migration task entirely depends on the stability of batch software package replacement.

[0017] Figure 1 is a schematic diagram of the main steps of an adaptive iterative software package replacement method of the present invention. As Figure 1 shown, an adaptive iterative software package replacement method in this embodiment mainly includes the following steps S1 - step S11.

[0018] S1: Target software package repository configuration After the operating system migration starts, first back up the repo file of the original operating system, and then configure the target software package repository according to the target operating system to prepare for batch software package replacement.

[0019] S2: Generate a preliminary software package replacement set After the target software package repository configuration is completed, batch software package replacement begins. First, use the software package manager to execute the replacement instruction on the local software package set (i.e., the set of software packages already installed in the environment), and at this time, a preliminary software package replacement set will be automatically generated according to the default rules of the software package manager (i.e., the default is to replace with the highest version of the software packages in the target software package repository).

[0020] In this embodiment, the initially generated software package replacement set is not necessarily the correct one and needs further optimization because problems such as missing dependencies and file conflicts may occur during the replacement process, resulting in replacement failure. After the initially generated software package replacement set is completed, the adaptive iterative software package replacement technology will be used to continuously optimize this software package set.

[0021] S3: Initialize the historical problem software package list Initialize the historical problem software package list as an empty list. The historical problem software package list is used to store all problem software packages identified after historical software package replacement fails. Since there are no problem software packages before the first round of software package replacement, this list is initialized as an empty list.

[0022] S4: Initialize the current round's problem software package list Initialize the current round's problem software package list as an empty list. The current round's problem software package list is used to store the problem software packages in the current round and the historical problem software packages. Since there are no problem software packages before the first round of software package replacement, this list is initialized as an empty list.

[0023] S5: Execute software package replacement Use the software package manager to perform a replacement on the current software package replacement set (when step S5 is executed for the first time, the current software package replacement set is the initially generated software package replacement set).

[0024] S6: Determine whether the software package replacement is successful After the software package replacement is completed, determine whether the replacement is successful based on the return code of the software package manager (usually, a return code of 0 indicates a successful replacement). If the replacement is successful, it proves that the current software package replacement set is correct and the operating system migration is successful, and the migration process exits; if the replacement fails, identify the problem software package.

[0025] S7: Identify the problem software package After the software package replacement fails, enter this stage to identify the problem software packages in the current round.

[0026] In one implementation, taking the YUM software package manager as an example, the method for identifying problem software packages is as follows: In YUM, problem software packages can be identified according to the stage at which software package conflicts occur; For example, in the build transaction stage, the software package dependency relationships are parsed, the transaction set is packaged, and no software package installation is performed. In this stage, problems such as missing software package dependencies and multi-version conflicts of software packages may occur; For example, in the execute transaction stage, including software package download, software package check, software package transaction test, etc., problems such as file conflicts and other abnormal software package transaction executions may occur in this stage.

[0027] The specific problem description and its identification method are as follows: (1) Package dependency missing Package dependency missing means that the packages in the target repository lack installation dependencies, resulting in failure to install and causing batch package replacement to fail.

[0028] In YUM, packages with missing dependencies can be obtained through reqPo (package instances with unfulfillable dependencies). This instance stores information such as the package name, version, and architecture of the problematic package, and the package corresponding to the reqPo instance is identified as the problematic package.

[0029] (2) Multiple package version conflicts Multiple package version conflicts mean that when there are multiple versions of a package in the target repository, the package manager will automatically search for and install the highest version of the package. However, if the highest version of the package does not meet the dependency requirements, the existing package replacement technology will not automatically query other packages that meet the dependency requirements but will directly report an error, causing batch package replacement to fail.

[0030] In YUM, packages with multiple version conflicts can be obtained through reqTup (the name, flags, and version of the package required to satisfy the dependencies). Traverse all versions of this package in the target repository. If a certain version does not meet the description of reqTup, it proves that this version should not be installed, and it is identified as the problematic package.

[0031] (3) Abnormal package transaction execution Abnormal package transaction execution means that if there are file conflicts between the packages in the target repository and the local packages, the existing package replacement technology will not automatically skip the packages with file conflicts, resulting in batch package replacement failure.

[0032] In YUM, 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 packages are identified as the problematic packages.

[0033] In another implementation, when the user uses the DNF package manager, the problematic packages can be identified by string matching the problem description. This embodiment does not limit the specific package manager used by the system.

[0034] S8: Add to the list of problematic packages in this round After the problematic packages are identified, they are added to the list of problematic packages in this round. This list is a globally shared variable that can ensure that all problematic packages are added to this variable; generally, this globally shared variable is implemented through the singleton pattern to ensure the uniqueness of this globally shared variable in multiple rounds of package replacement.

[0035] S9: Determine whether a new problematic software package is recognized After adding the problematic software packages recognized in this round to the list of problematic software packages in this round, determine whether the list of problematic software packages in this round is the same as the list of historical problematic software packages. If they are the same, it proves that the software package replacement in this round fails and no new problematic software packages are recognized. Then the adaptive iterative software package replacement fails, the operating system migration fails, and the migration process exits. If they are different, it proves that although the software package replacement in this round fails, new problematic software packages are recognized.

[0036] S10: Add to the list of historical problematic software packages After recognizing a new problematic software package, add it to the list of historical problematic software packages for comparison with the list of problematic software packages in this round of the next round to determine whether a new problematic software package is recognized in the next round.

[0037] S11: Iteratively optimize the software package replacement set In the current software package replacement set, exclude the list of historical problematic software packages, iteratively optimize the software package replacement set, and re-enter step S5 for software package replacement.

[0038] Based on the above steps S1 - S11, the adaptive iterative software package replacement method proposed by the present invention executes a software package replacement task multiple times, can recognize the problematic software packages after each round of replacement failure, and iteratively optimize the software package replacement set until a correct software package replacement set (i.e., a software package replacement set that will not cause migration failure) is generated. It solves the problem of operating system migration failure caused by missing software package dependencies, multi-version conflicts of software packages, abnormal execution of software package transactions, etc. In particular, in step S7 of this embodiment, the strategy for recognizing problematic software packages can be manually adjusted according to different software package managers, and the rest of the stages do not need to be modified, which is convenient for extension.

[0039] This embodiment can automatically generate a correct software package replacement set during the software package batch replacement stage of the operating system, solve the problem of migration failure caused by abnormal software package replacement during the existing operating system migration, greatly improve the stability of the operating system migration, and reduce the manual processing cost.

[0040] It should be noted that although the above steps are described in a specific order, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not necessarily need to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these changes are all within the protection scope of the present invention.

[0041] So far, the technical solution of the present invention has been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. An adaptive iterative software package replacement method, characterized in that, It includes the following steps: 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 instruction on the local software package set, defaulting to replace with the highest version of the software packages in the target software package repository, and generate a preliminary software package replacement set; S3: Initialize the historical problem software package list as an empty list, and the historical problem software package list is used to store all problem software packages identified after the failure of historical software package replacement; S4: Initialize the current round of problem software package list as an empty list, and the current round of problem software package list is used to store the problem software packages of the current round and the historical problem software packages; S5: Use the package manager to perform a replacement on the current software package replacement set; S6: Judge whether the replacement is successful according to the return code of the package manager. If the replacement is successful, the current software package replacement set is correct and the operating system migration is successful, then exit the migration process. If the replacement fails, execute step S7; S7: Identify the problem software packages of the current round; S8: Add the identified problem software packages to the current round of problem software package list; S9: Judge whether the current round of problem software package list and the historical problem software package list are the same. If they are the same, it means that the software package replacement of this round fails and no new problem software packages are identified, then the adaptive iterative software package replacement fails and the operating system migration fails, and exit the migration process; If they are different, it means that the software package replacement of this round fails, but new problem software packages are identified, then execute step S10; S10: Add the identified new problem software packages to the historical problem software package list for comparison with the current round of problem software package list in the next round; S11: Exclude the historical problem software package list from the current software package replacement set, iteratively optimize the software package replacement set, and return to step S5 for software package replacement.

2. The adaptive iterative software package replacement method according to claim 1, wherein When using the YUM package manager, the identification of the problem software packages of the current round includes the following steps: In the build transaction stage, parse the software package dependencies and package the transaction set without installing the software packages. In this stage, problems such as missing software package dependencies and multi-version conflicts of software packages may occur; In the execute transaction stage, it includes software package download, software package check, and software package transaction test. In this stage, problems such as abnormal execution of software package transactions may occur.

3. An adaptive iterative software package replacement method according to claim 2, characterized in that In the YUM package manager, the software packages with missing software package dependencies are obtained through the package instance with unfulfilled dependencies. This instance stores the package name, version, and architecture information of the problem software package, and the software package corresponding to this instance is identified as a problem software package.

4. An adaptive iterative software package replacement method according to claim 2, characterized in that In the YUM package manager, the software packages with multi-version conflicts of software packages are obtained through reqTup. The reqTup represents the name, flag, and version of the package required to satisfy the dependencies. Traverse all packages in the target repository that do not meet the reqTup and identify them as problem software packages.

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

Images