Application software compatibility guarantee method and system, medium and product

Abstract

The invention discloses an application software compatibility guarantee method and system, a medium and a product. The method comprises the following steps: establishing a system compatibility baseline; constructing an application guard list; in response to a system software package change operation initiated by the package manager, before the system software package change operation is executed, pre-change check is triggered, the influence of the system software package change operation on the application software in the application guard list is analyzed, and if the compatibility influence does not exist, the change operation is allowed to be executed; if the compatibility influence exists, waiting for user confirmation, and if an instruction that the user confirms to continue changing is received, allowing the package manager to continue executing the system software package changing operation; and if an instruction of cancelling the change by the user is received or an instruction of confirming to continue the change is not received after a set time is exceeded, terminating the current system software package change operation of the package manager. According to the method, the safety, the controllability and the reliability of the system updating and maintaining process can be enhanced.

Description

Technical Field

[0001] This invention relates to the field of system package upgrade technology for Linux operating systems, and specifically to a method, system, medium, and product for ensuring application software compatibility. Background Technology

[0002] In the long-term operation and maintenance of Linux servers, users typically need to perform system upgrades, downgrades, business adaptations, or extensions based on business requirements. These operations often involve the management of system software packages, including but not limited to package installation, uninstallation, and version switching. However, because different business systems (application software, referred to as applications in this article) may have different requirements for underlying dependencies and their versions, users often need to configure the dependency environment separately for each business system, and may even need to upgrade the entire operating system to meet business requirements. Such operations may cause dependency conflicts and version incompatibility issues, leading to errors in application operation, specifically manifested as follows: Missing dynamic link library (DLL) dependencies: When a Linux application is compiled, its ELF file records a list of required DLLs (such as the DT_NEEDED entry). Changes to system packages (such as upgrades or removals) may cause critical dependent DLLs to be missing at runtime. In this case, the dynamic linker (ld.so) will be unable to load the application, leading to abnormal process loading or direct termination.

[0003] ABI / API compatibility breaches: While basic dynamic library dependencies are satisfied, deeper interface dependencies can trigger runtime crashes. These dependencies involve function signatures, data structures, and calling conventions provided by the dynamic library, and their stability is guaranteed by the Application Binary Interface (ABI) and Application Programming Interface (API). If an upgrade of a dependent dynamic library introduces incompatible changes (such as SONAME version jumps or function parameter modifications), the ELF file may trigger segmentation faults, stack corruption, or undefined behavior when calling related symbols.

[0004] System risks arising from system administrator actions: When fixing CVE vulnerabilities or functional defects, system administrators may inadvertently introduce unexpected changes to dependent environments. For example, forcibly upgrading critical system packages (such as libstdc++, python3) may cause a break in the dependency chain, and rollback operations may cause further problems due to inconsistencies in the version database of package managers (such as rpm). Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide an application software compatibility assurance method, system, medium, and product that addresses the above-mentioned problems in the prior art. This invention aims to realize a mechanism for pre-detection, early warning, and controllable execution, so as to proactively identify and warn of the potential compatibility impact of system software package changes on existing applications marked as compatible in the system before the system software package change operation is completed through the package manager, thereby enhancing the security, controllability, and reliability of the system update and maintenance process.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for ensuring application software compatibility includes the following steps: S1. Establish a system compatibility baseline: Scan the system's dynamic library paths and ldconfig cache to generate a system compatibility baseline containing the identification information, exported symbol information, and version information of all current dynamic libraries in the system. S2. Construct an application protection list: Based on the system compatibility baseline, perform compatibility checks on each target application to be protected, and include the target applications that pass the check into the application protection list. The application protection list stores the dependency information of each target application that passes the check. S3. In response to a system package change operation initiated by the package manager, a pre-change check is triggered before the system package change operation is executed. The impact of the system package change operation on the application software in the application protection list is analyzed. If the analysis results show that the system package change operation has no compatibility impact on the application software in the application protection list, the change operation is allowed to be executed. If the analysis results show that the system package change operation has a compatibility impact on the application software in the application protection list, user confirmation is awaited. If a user confirmation to continue the change is received, the package manager is allowed to continue executing the system package change operation. If a user cancellation instruction is received or no confirmation to continue the change is received after a set time, the current system package change operation of the package manager is terminated.

[0007] Optionally, performing compatibility checks on each target application to be protected based on the system compatibility baseline includes: traversing each target application and performing the following compatibility check steps for each target application to be protected: Parse the target application's ELF file to obtain a list of dynamic libraries that the target application depends on and all unresolved symbols in the ELF file; Perform a library availability check: compare the list of dynamic libraries that the target application depends on with the dynamic library identification information in the system compatibility baseline; if all dynamic libraries in the list can be found to have matching dynamic library identification information in the system compatibility baseline, the target application is determined to have passed the library availability check; otherwise, it is determined to have failed. Perform an unresolved symbol resolvability check: Check if all unresolved symbols in the target application's ELF file exist in the corresponding exported symbol information in the system compatibility baseline. If they exist, the unresolved symbol resolvability check is considered passed; otherwise, it is considered failed. Perform version constraint check: Check whether the ABI version requirements of all unresolved symbols in the target application's ELF file fall within the version range supported by the corresponding dynamic library in the system compatibility baseline. If they are within the supported version range, the version constraint check is considered to have passed; otherwise, it is considered to have failed. If the target application passes the inventory existence check, unresolved symbol resolvability check, and version constraint check, then the compatibility check of the target application is considered to have passed; otherwise, it is considered to have failed.

[0008] Optionally, the following compatibility check steps may be performed before each target application to be protected: Determine whether the target application is in a preset whitelist. If it is in the whitelist, skip the target application. If it is not in the whitelist, perform the compatibility check step for the target application.

[0009] Optionally, if the analysis results indicate that the system software package change operation has a compatibility impact on the applications in the application protection list, a conflict report is generated and user confirmation is awaited.

[0010] Optionally, in step S2, the target applications that pass the inspection are included in the application protection list, and these target applications are marked as compatible applications in the application protection list; in step S3, if the analysis results show that the system package change operation has a compatibility impact on the application software in the application protection list, the affected application software is recorded, and after receiving the user's confirmation to continue the change, the following operations are performed on the application protection list: the affected application software is marked as incompatible application, and the dependency information of the application protection list is updated.

[0011] Optionally, the system is configured with a pre-change check execution switch. When the pre-change check switch is turned off, it indicates that the pre-change check is not triggered before the system software package change operation is executed, and the system software package change operation is executed directly.

[0012] Optionally, the system is configured with a system package exclusion function, which allows specific system packages to be excluded from the scope of pre-change checks through settings.

[0013] Furthermore, the present invention also provides an application software compatibility assurance system, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the application software compatibility assurance method.

[0014] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the application software compatibility assurance method by a processor.

[0015] In addition, the present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the application software compatibility assurance method via a processor.

[0016] Compared with the prior art, the present invention has the following main advantages: This invention generates a system compatibility baseline by scanning system dynamic library paths and ldconfig cache, providing a real-time environment snapshot covering all dynamic library identifiers, exported symbols, and version information of the current system. Based on this system compatibility baseline, an application protection list is constructed, enabling precise screening and centralized management of the compatibility status of target applications, clearly defining and listing the objects to be protected. By triggering pre-change checks before system software package changes are executed, the impact of changes on applications in the protection list is analyzed, and the analysis results are linked to user decisions, achieving a fundamental shift from "passive fault handling" to "proactive risk warning and controllable operation." This effectively eliminates the risk of application crashes caused by blind changes, significantly enhancing the security, controllability, and reliability of the system update and maintenance process. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the execution flow of the method of the present invention.

[0018] Figure 2 This is a schematic diagram of the execution flow of step S3 of the present invention.

[0019] Figure 3 This is a schematic diagram of the execution flow of step S2 of the present invention. Detailed Implementation

[0020] The technical solution of the present invention will now be described in further detail with reference to the accompanying drawings.

[0021] like Figure 1 and Figure 2 As shown, the application software compatibility assurance method of this embodiment includes the following steps: S1. Establish a system compatibility baseline: Scan the system's dynamic library paths (e.g., / usr / lib, / lib64) and ldconfig cache ( / etc / ld.so.cache) to generate a system compatibility baseline containing the identification information, exported symbol information, and version information of all current dynamic libraries in the system. S2. Construct an application protection list: Based on the system compatibility baseline, perform compatibility checks on each target application to be protected, and include the target applications that pass the check into the application protection list. The application protection list stores the dependency information of each target application that passes the check. S3. In response to a system package change operation initiated by the package manager, a pre-change check is triggered before the system package change operation is executed. This check analyzes the impact of the system package change operation on the application software in the application protection list. If the analysis results show that the system package change operation has no compatibility impact on the application software in the application protection list, the change operation is allowed to proceed. If the analysis results show that the system package change operation has a compatibility impact on the application software in the application protection list, the system package change operation waits for user confirmation. If the user confirms the change and continues, the package manager is allowed to continue executing the system package change operation. If the user cancels the change or no confirmation is received after a set time, the system package change operation by the package manager is terminated.

[0022] This embodiment's application software compatibility assurance method generates a system compatibility baseline by scanning the system's dynamic library paths and ldconfig cache, providing a real-time environment snapshot covering all dynamic library identifiers, exported symbols, and version information of the current system. Based on this system compatibility baseline, an application protection list is constructed, enabling precise screening and centralized management of the compatibility status of target applications, clearly defining and listing the objects to be protected. By triggering pre-change checks before system software package change operations are executed, the impact of changes on applications in the protection list is analyzed, and the analysis results are linked to user decisions, achieving a fundamental shift from "passive fault handling" to "proactive risk warning and controllable operation." This effectively eliminates the risk of application crashes caused by blind changes, significantly enhancing the security, controllability, and reliability of the system update and maintenance process.

[0023] Furthermore, in this embodiment, the identification information of the dynamic library in the system compatibility baseline refers to the SONAME of the dynamic library and the exported symbol information, which are obtained by parsing the .dynsym section of the dynamic library from the exported symbol table of the corresponding dynamic library.

[0024] Furthermore, in this embodiment, the compatibility check for each target application to be protected based on the system compatibility baseline includes: traversing each target application and performing the following compatibility check steps for each target application to be protected: The target application's ELF file is parsed to obtain a list of dynamic libraries that the target application depends on, as well as all unresolved symbols in the ELF file. Specifically, by parsing the target application's .dynamic section, the DT_NEEDED entry is extracted to construct a complete runtime dynamic library dependency graph, including direct dynamic library dependencies (such as libssl.so.3) and transitive dynamic library dependencies (such as libcrypto.so.10). It should be noted that the DT_NEEDED entry records the SONAME of the dynamic library; unresolved symbols in the ELF file refer to symbols of type UND. Perform a library availability check: Compare the list of dynamic libraries that the target application depends on with the dynamic library identification information in the system compatibility baseline; if all dynamic libraries in the list can be found to have matching dynamic library identification information in the system compatibility baseline, the target application is deemed to have passed the library availability check; otherwise, it is deemed to have failed. Perform unresolved symbol resolvability check: Check if all unresolved symbols in the target application's ELF file exist in the corresponding exported symbol information in the system compatibility baseline. If they exist, the unresolved symbol resolvability check is considered passed; otherwise, it is considered failed. Perform version constraint checks: Check whether the ABI version requirements of all unresolved symbols in the target application's ELF file fall within the version range supported by the corresponding dynamic library in the system compatibility baseline. If they are within the supported version range, the version constraint check is considered passed; otherwise, it is considered failed. Specifically, after finding the information matching the unresolved symbol in the corresponding exported symbol information in the system compatibility baseline, determine the matching dynamic library and check whether the version information of the dynamic library meets the ABI version requirements of the unresolved symbol.

[0025] If the target application passes the inventory existence check, unresolved symbol resolvability check, and version constraint check, then the compatibility check of the target application is considered to have passed; otherwise, it is considered to have failed.

[0026] Furthermore, in this embodiment, the dependency information of each target application in the application guardian list includes library dependency information and interface dependency information. Library dependency information includes the SONAME in the DT_NEEDED entry obtained by parsing the corresponding application's ELF file, the dynamic library providing the SONAME, the system package (rpm package) to which the dynamic library belongs, and the library dependency compatibility status value (true if the library presence check is passed, false otherwise). Interface dependency information includes the name of the unresolved symbol (UND symbol) obtained by parsing the corresponding application's ELF file, the ABI version required by the unresolved symbol, the SONAME of the dynamic library providing the unresolved symbol, the dynamic library providing the unresolved symbol, the system package (rpm package) to which the dynamic library belongs, and the interface compatibility status value of the interface. This interface compatibility status value is jointly determined by the symbol reachability check and the ABI version constraint check. The interface compatibility status value is true if and only if the symbol exists in the exported symbol table of the target dynamic library and its version requirement falls within the range of ABI versions supported by the dynamic library; otherwise, it is false.

[0027] Furthermore, such as Figure 3 As shown, in this embodiment, before performing the following compatibility check steps for each target application to be protected (in this embodiment, all applications in the system application list; in other embodiments, a separate list can be created to store applications that need to be checked for compatibility, or the compatibility check steps can be performed separately via a command line with the target application path), the following steps are also included: The system determines whether the target application is on a pre-defined whitelist. If it is, the application is skipped; otherwise, a compatibility check is performed. Whitelisted applications: Core operating system components or critical applications with rigorous certification and proven compatibility are exempt from the check. Non-whitelisted applications: Newly deployed applications, applications of uncertain origin, or applications requiring close monitoring undergo a rigorous, in-depth compatibility check. This approach allows limited resources to be allocated where they are most needed.

[0028] Furthermore, in this embodiment, in step S2, the target applications that pass the inspection are included in the application protection list, and these target applications are marked as compatible applications in the application protection list; in step S3, if the analysis results show that the system software package change operation has a compatibility impact on the application software in the application protection list, the affected application software is recorded. After receiving the user's confirmation to continue the change, the following operations are performed on the application protection list: the affected application software is marked as incompatible applications, and the dependency information of the application protection list is updated. This enables the application protection list to be updated and the system software package to be changed simultaneously after receiving the user's confirmation.

[0029] As an optional implementation, if the analysis results indicate that the system package change operation has a compatibility impact on applications in the application protection list, a conflict report is generated and user confirmation is awaited. The core of the pre-change analysis process lies in simulating an impending system environment change and re-performing compatibility checks within this simulated environment. The specific analysis process is as follows: Taking an RPM package as an example, the analysis process does not directly install the system package, but rather parses its core files. Specifically, after decompression, the file list of the target RPM package is read, and the dynamic library files (such as libfoo.so.major) and the ELF header of the executable file provided within the package are located and parsed. By parsing the .dynamic and .dynsym sections of these ELF files, the new dynamic library SONAME list, exported symbol table, and supported ABI version information provided by the RPM package are extracted. Simultaneously, other system libraries that the package may depend on are identified (obtained through the DT_NEEDED entry). Next, a simulated system compatibility baseline is generated and an impact analysis is performed. The extracted information is compared with the current system compatibility baseline to generate a simulated system compatibility baseline. This simulated system compatibility baseline reflects the system environment state after the target RPM package is successfully installed, showing the status of added, upgraded, or removed dynamic libraries. Subsequently, the dependency information (library dependencies, interface dependencies) of each application in the application guardian list is compared with this simulated baseline, and library presence checks, symbol resolvability checks, and ABI version constraint checks are re-executed. Finally, an accurate conflict report is generated. Based on the comparison results, it is possible to accurately determine which applications in the application guardian list will experience compatibility issues after package changes and pinpoint the specific reasons, for example: "Application A becomes incompatible because the dynamic library libold.so.1 is replaced by the new version libnew.so.2 in the package and the symbol obsolete_function is missing." This conflict report, along with change suggestions (continue the change, cancel the change), is submitted to the user for confirmation.

[0030] As an optional implementation, marking affected applications as incompatible and updating the dependency information in the application guardian list includes: for each target application in the application guardian list, comparing and verifying the dependency information (including library and interface dependencies) recorded in its guardian list with a simulated system compatibility baseline. If the check passes, its "compatible application" label is maintained, and the compatibility status values ​​(library dependency compatibility status value, interface compatibility status value) in its dependency information are kept true. If the check fails, it is marked as an "incompatible application," and the corresponding compatibility status value is updated to false. More importantly, when a re-check reveals that the application's dependencies have actually changed due to system changes but the new environment is still compatible (e.g., changes to the dynamic library providing the SONAME and the system package to which the dynamic library belongs), the system automatically updates the dependency information item corresponding to the target application in the application guardian list, ensuring that the guardian list data remains consistent with the current system status. Of course, in other embodiments, after completing the system package change operation, a scan can be performed to scan the current system's dynamic library paths and ldconfig cache to generate a new system compatibility baseline. Based on the new system compatibility baseline and the dependency information of each target application in the application guardian list, a compatibility check can be performed on the corresponding target applications, and then the dependency information of the application guardian list can be updated according to the check results.

[0031] Furthermore, in this embodiment, the system is configured with a pre-change check execution switch. When the pre-change check switch is turned off, it indicates that the pre-change check is not triggered before the system package change operation is executed, and the system package change operation is executed directly. The enabling and disabling of the pre-change check execution switch is controlled through command-line parameters of the package manager and a separate configuration file. Specifically, the setting made through the first command-line parameter (e.g., `dnf update --compat-guard=off`) only applies to the currently initiated system package change operation, achieving temporary control over the pre-change check function; the setting made through the first configuration file (e.g., setting `compat-guard=true` in ` / etc / compat.conf`) remains effective while the first configuration file is in effect, achieving persistent control over the pre-change check function. Moreover, the control priority of the first command-line parameter is higher than that of the first configuration file; when the settings of the first command-line parameter and the first configuration file conflict, the setting of the first command-line parameter prevails.

[0032] Furthermore, in this embodiment, the system is configured with a system package exclusion function, which allows specific system packages to be excluded from the scope of pre-change checks through settings. The system package exclusion function is controlled via a second command-line parameter of the package manager and a separate second configuration file. Exclusion settings for specific packages via command-line parameters (e.g., `--exclude=pkgA`) only apply to the currently initiated system package change operation, achieving temporary exclusion; exclusion settings for specific system packages via the second configuration file remain effective while the second configuration file is in effect, achieving permanent exclusion. This exclusion mechanism effectively ensures flexibility and adaptability, supporting both temporary debugging or emergency change needs and continuous exemption management of known compatible system packages from pre-change checks.

[0033] As an optional implementation, if a system software package is modified without performing a pre-change check, the dynamic libraries affected by the change and the related interface dependency information are recorded, and a change impact record is generated for the administrator to query.

[0034] As an optional implementation, the application software compatibility assurance method of this embodiment can be implemented by deploying a compatibility assurance tool in the system. This tool possesses the following characteristics in data management to ensure its practicality and continuity in actual operation and maintenance: 1. Guardian List Data Persistence: The application's guardian list data is persistently stored in a manner independent of the tool itself. When a user uninstalls this compatibility assurance tool, the stored guardian list data will not be automatically deleted (unless the user manually deletes it). When the tool is subsequently reinstalled or upgraded, the new instance can automatically discover, load, and reuse the previously persistently stored guardian list data, thereby achieving smooth inheritance and seamless recovery of guardian state and ensuring the continuity of operational strategies; 2. Manageable Guardian Applications: To adapt to dynamic adjustments in business systems, this tool provides a management interface for guardian applications. Users can use this interface to proactively remove specified target applications that no longer need protection from the application guardian list. This mechanism ensures that the guardian list can be dynamically updated as business changes occur, maintaining its relevance and effectiveness at all times, and avoiding ineffective monitoring of applications that have been decommissioned or migrated. 3. A plugin has been developed in the package manager (such as DNF / YUM) to perform a pre-change check by calling the API interface of the compatibility assurance tool before making changes to the system package, and to update the dependency information in the application guardian list by calling the API interface of the compatibility assurance tool after the user confirms the change.

[0035] In addition, this embodiment also provides an application software compatibility assurance system, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute an application software compatibility assurance method.

[0036] In addition, this embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute an application software compatibility assurance method via a processor.

[0037] In addition, this embodiment also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute an application software compatibility assurance method via a processor.

[0038] Those skilled in the art will understand that the technical solutions provided by the embodiments of this application may be in the form of a method, system, or computer program product. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create an implementation for the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.

[0039] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for ensuring application software compatibility, characterized in that, Includes the following steps: S1. Establish a system compatibility baseline: Scan the system's dynamic library paths and ldconfig cache to generate a system compatibility baseline containing the identification information, exported symbol information, and version information of all current dynamic libraries in the system. S2. Construct an application protection list: Based on the system compatibility baseline, perform compatibility checks on each target application to be protected, and include the target applications that pass the check into the application protection list. The application protection list stores the dependency information of each target application that passes the check. S3. In response to a system package change operation initiated through the package manager, a pre-change check is triggered before the system package change operation is executed to analyze the impact of the system package change operation on the application software in the application protection list. If the analysis results show that the system package change operation has no compatibility impact on the application software in the application protection list, then the change operation is allowed to be executed. If the analysis results indicate that the system software package change operation has a compatibility impact on the application software in the application protection list, then wait for user confirmation. If the user confirms to continue the change, the package manager is allowed to continue executing the system software package change operation. If the user cancels the change or no confirmation is received after a set time, the package manager terminates the current system software package change operation.

2. The application software compatibility assurance method according to claim 1, characterized in that, Based on the system compatibility baseline, the compatibility check for each target application to be protected includes: traversing each target application and performing the following compatibility check steps for each target application to be protected: Parse the target application's ELF file to obtain a list of dynamic libraries that the target application depends on and all unresolved symbols in the ELF file; Perform a library availability check: compare the list of dynamic libraries that the target application depends on with the dynamic library identification information in the system compatibility baseline; if all dynamic libraries in the list can be found to have matching dynamic library identification information in the system compatibility baseline, the target application is determined to have passed the library availability check; otherwise, it is determined to have failed. Perform an unresolved symbol resolvability check: Check if all unresolved symbols in the target application's ELF file exist in the corresponding exported symbol information in the system compatibility baseline. If they exist, the unresolved symbol resolvability check is considered passed; otherwise, it is considered failed. Perform version constraint check: Check whether the ABI version requirements of all unresolved symbols in the target application's ELF file fall within the version range supported by the corresponding dynamic library in the system compatibility baseline. If they are within the supported version range, the version constraint check is considered to have passed; otherwise, it is considered to have failed. If the target application passes the inventory existence check, unresolved symbol resolvability check, and version constraint check, then the compatibility check of the target application is considered to have passed; otherwise, it is considered to have failed.

3. The application software compatibility assurance method according to claim 2, characterized in that, Before performing the following compatibility checks for each target application to be protected, the following steps are also included: Determine whether the target application is in a preset whitelist. If it is in the whitelist, skip the target application. If it is not in the whitelist, perform the compatibility check step for the target application.

4. The application software compatibility assurance method according to claim 1, characterized in that, If the analysis results indicate that the system package change operation has a compatibility impact on the applications in the application protection list, a conflict report will be generated and user confirmation will be awaited.

5. The application software compatibility assurance method according to claim 1, characterized in that, In step S2, the target applications that pass the inspection are included in the application protection list, and these target applications are marked as compatible applications in the application protection list. In step S3, if the analysis results show that the system package change operation has a compatibility impact on the application software in the application protection list, the affected application software is recorded. After receiving the user's confirmation to continue the change, the following operations are performed on the application protection list: the affected application software is marked as incompatible application, and the dependency information of the application protection list is updated.

6. The application software compatibility assurance method according to claim 1, characterized in that, The system is equipped with a pre-change check execution switch. When the pre-change check switch is turned off, it means that the pre-change check will not be triggered before the system software package change operation is executed, and the system software package change operation will be executed directly.

7. The application software compatibility assurance method according to claim 1, characterized in that, The system is configured with a system package exclusion function, which allows you to exclude specific system packages from the scope of pre-change checks through settings.

8. An application software compatibility assurance system, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to perform the application software compatibility assurance method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the application software compatibility assurance method according to any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the application software compatibility assurance method according to any one of claims 1 to 7 via a processor.

Images