Clarm software package compatibility detection and verification method, device and equipment and storage medium

Abstract

The invention discloses a method, a device and equipment for detecting and verifying compatibility of a opened software package and a storage medium, and relates to the technical field of software package compatibility detection.The method comprises the steps of extracting and analyzing metadata of the opened package to generate software package dependency data; the scanning system performs static dependency analysis according to the software package dependency data to generate static dependency data; performing a dynamic behavior test to generate dynamic test data; and generating a compatibility report according to the static dependency data and the dynamic test data. Static analysis is carried out on the open package metadata layer, quantitative evaluation is carried out from the static dependency satisfaction degree and the API change degree, dynamic function consistency verification is combined, and dynamic testing is carried out from the whole life cycle of installation and operation, version iteration and system migration. Compatibility verification of system calling hierarchy comprehensive coverage is carried out on the open software package in a local system environment, an upgraded target system environment and a version updating environment, and the problems of system crash and the like caused by compatibility risks are avoided.

Description

Technical Field

[0001] This invention relates to the field of software package compatibility testing technology, and in particular to an open software package compatibility testing and verification method, apparatus, device, and storage medium. Background Technology

[0002] Kaiming packages are a domestically developed application container format. With the rapid development of the information technology application innovation industry (IT innovation), domestic operating systems (such as OpenKylin and Galaxy Kylin) have entered a stage of large-scale application. As a core carrier for IT innovation software delivery, the compatibility and migration capabilities of Kaiming packages are crucial for building an operating system ecosystem. During version upgrades and system platform migrations, changes in dependencies and environments can lead to compatibility issues such as missing dependencies, preventing the packages from installing, uninstalling, or running correctly.

[0003] Because Kaiming packages are a domestic application containerization format that adopts a two-layer structure of "application container + metadata," unlike traditional deb / rpm package formats which use a single archive structure and are tightly coupled to the system environment, Kaiming packages achieve decoupling between applications and systems through layered isolation of base (basic environment), runtime (runtime library), and depend (general dependencies). However, traditional package compatibility testing tools, when faced with Kaiming packages, cannot parse the two-layer container structure and layered metadata of Kaiming packages due to differences in structural parsing. They cannot verify runtime behavior in the isolated sandbox designed by Kaiming packages, resulting in the inability to obtain the dependency relationships of Kaiming packages, as well as insufficient control and adaptation efficiency regarding the cross-system migration capabilities and upgrade risks of Kaiming packages. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for testing and verifying compatibility of open-source software packages, in order to solve the technical problem of difficulty in performing dependency resolution and verifying the runtime behavior of open-source software packages in an isolated sandbox.

[0005] In a first aspect, embodiments of the present invention provide a method for native compatibility testing of open-source software packages, including:

[0006] S101, parse the metadata of the Kaiming software package to obtain the software package dependency data information;

[0007] S102, Scan the local system, perform static dependency analysis on the local system based on the software package dependency data information, and obtain static dependency pass information;

[0008] S103, Perform dynamic behavior testing on the Kaiming software package and obtain dynamic test pass information;

[0009] S104 generates a native compatibility report for the open-source software package based on static dependency pass information and dynamic test pass information.

[0010] Furthermore, S101 includes:

[0011] Obtain the metadata of the Kaiming package. Based on the base, runtime, and depends fields of the metadata, read the basic environment dependencies, special environment runtime dependencies, and package dependencies of the Kaiming package to obtain package dependency data information.

[0012] Furthermore, S102 includes:

[0013] Scan the local system to obtain the list of base dependencies, runtime dependencies, and depend dependencies already installed on the local system, and compare them with the package dependency data information to determine the number of dependencies contained in the package dependency data information on the local system, thus obtaining static dependency information.

[0014] Secondly, embodiments of the present invention provide an open-source software package migration compatibility verification method, including:

[0015] S201, parse the metadata of the Kaiming software package to obtain the software package dependency data information;

[0016] S202, upgrade the local system to the baseline system version, scan the upgraded target system version, perform static dependency analysis on the target system based on package dependency data, and obtain the static dependency pass information after the upgrade;

[0017] S203, In the upgraded target system, perform dynamic behavior testing on the Kaiming software package and obtain the upgraded dynamic test pass information;

[0018] S204 generates an open-source software package migration compatibility report based on the static dependency pass information and the dynamic test pass information after the upgrade.

[0019] Thirdly, embodiments of the present invention provide an open-source software package upgrade compatibility detection method, including:

[0020] S301, parse the metadata of the Kaiming software package and the upgraded Kaiming software package respectively to obtain the API data information of the software package and the API data information of the upgraded software package;

[0021] S302, Based on the current version of the ELF file list and the upgraded ELF file list, as well as based on the package API data information and the upgraded package API data information, perform static change comparisons to obtain static change data information;

[0022] S303 uses the Kaiming software package and the upgraded version of the Kaiming software package to perform dynamic upgrade testing and generate dynamic test data information for version upgrade.

[0023] S304 generates an upgrade compatibility report for the Kaiming software package based on static change data and dynamic test data for version upgrades.

[0024] Furthermore, S301 includes:

[0025] Obtain the metadata of the Kaiming software package and the upgraded Kaiming software package respectively, read the version information according to the version field of the metadata, scan all ELF files, and save them as the current version ELF file list and the upgraded version ELF file list respectively;

[0026] Based on the ELF file list, read the APIs provided by all ELF files and generate the package API data information for the current version and the upgraded package API data information for the upgraded version.

[0027] Furthermore, S302 includes:

[0028] By comparing the current version's ELF file list with the upgraded version's ELF file list, ELF file change data information is generated based on the differences in the ELF files;

[0029] Using the current version of the software package API data and the upgraded version of the software package API data, API interface change data information is generated based on the differences in API interfaces;

[0030] Static change data information is generated based on the change data information in the ELF file and the API interface.

[0031] Fourthly, embodiments of the present invention provide an open-source software package compatibility testing and verification device, comprising:

[0032] The metadata analysis module is used to parse the metadata of the Kaiming software package to form software package dependency data information or software package API data information;

[0033] The static testing module is used to perform static dependency analysis based on package dependency data and system environment to generate static dependency pass information under the current system version, or to perform static change comparison based on package API data to generate static change data information.

[0034] The dynamic testing module is used to perform dynamic behavior testing or dynamic upgrade testing on the Kaiming software package under the current system version, and generate dynamic test pass information or version upgrade dynamic test pass information.

[0035] The test report generation module is used to generate compatibility reports for the Kaiming software package based on static and dynamic test results.

[0036] Fifthly, embodiments of the present invention provide an electronic device, comprising:

[0037] One or more processors;

[0038] Storage device for storing one or more programs.

[0039] When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described open software package compatibility detection and verification method.

[0040] In a sixth aspect, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the above-described open software package compatibility detection and verification method.

[0041] This invention provides a method, apparatus, device, and storage medium for compatibility testing and verification of open-source software packages. The native compatibility testing method targets the two-layer architecture of open-source software packages—"application container + metadata"—by extracting the metadata layer content and performing static dependency analysis at three levels: base, runtime, and depend. It also conducts dynamic testing throughout the entire lifecycle of the package, from installation to startup and uninstallation. This comprehensive approach, covering both static and dynamic aspects, fully covers the system call layer of the open-source software package. It can detect runtime issues such as SELinux policy conflicts missed by static analysis, improving the efficiency of dependency analysis and reducing false positives. Furthermore, it can be executed through automated test scripts without manual intervention, filling the gap in testing tools for open-source package formats. This injects standardized quality assurance measures into the domestic operating system ecosystem and promotes improved efficiency in the delivery of domestically developed software. The migration compatibility verification method performs compatibility testing of open-source packages on the system after the baseline version is upgraded. By combining static and dynamic perspectives, it verifies the compatibility of open-source packages in system migration scenarios by combining static dependency satisfaction metric evaluation with dynamic functional consistency verification after migration. This significantly shortens the migration time of open-source packages across domestic operating systems, reduces the workload required for manual adaptation, and allows developers to perform automated dependency adaptation based on compatibility reports, reducing secondary development costs and improving the success rate of migration verification of open-source packages. The upgrade compatibility detection method parses different versions of the OpenMind package using metadata, extracts ELF files from the metadata to form an ELF file list, compares the changes in ELF files before and after the version upgrade, and then reads the API interface information of each ELF file to compare the API interface changes between the same ELF files before and after the version upgrade, generating static change data. Then, dynamic OpenMind package version upgrade and downgrade operations are performed. Combining the static change data and dynamic test data, an upgrade compatibility report for the OpenMind package is generated. By comparing API interface change differences from a static perspective, the interface changes of the OpenMind package before and after the version upgrade are identified. Combined with dynamic upgrade and downgrade tests, a version upgrade compatibility risk report is generated from multiple dimensions. This method has high accuracy in detecting API changes during version upgrades, can provide early warnings of most upgrade risks caused by interface incompatibility, avoids system crashes caused by version iterations, and ensures business continuity. Attached Figure Description

[0042] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0043] Figure 1 This is a flowchart of an open-source software package native compatibility detection method according to Embodiment 1 of the present invention;

[0044] Figure 2 This is a flowchart of an open-source software package migration compatibility verification method according to Embodiment 2 of the present invention;

[0045] Figure 3 This is a flowchart of an open software package upgrade compatibility detection method according to Embodiment 3 of the present invention;

[0046] Figure 4 This is a schematic diagram of the structure of an open software package compatibility testing and verification device according to Embodiment 4 of the present invention;

[0047] Figure 5 This is a structural diagram of the electronic device described in Embodiment 5 of the present invention. Detailed Implementation

[0048] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0049] The Kaiming package's two-layer structure of "application container + metadata," along with its three-layer metadata structure of base (basic environment), runtime (runtime library), and depend (general dependencies), enables application decoupling from the system and provides fine-grained sandbox access control. Traditional report management tools cannot parse the two-layer structure of the Kaiming package, leading to incomplete dependency extraction, missing version conflict detection, and reliance on the host system's global environment. This makes it impossible to verify the cross-system compatibility of the Kaiming package within an isolated sandbox, and to control its compatibility after upgrades or migrations. The following solutions are needed to overcome these problems and perform compatibility verification on the Kaiming package to assess the risks of upgrades and migrations, shorten the adaptation cycle, and improve the ecosystem quality of domestic operating systems.

[0050] Example 1

[0051] Figure 1 This embodiment of the invention provides a method for detecting the native compatibility of open-source software packages. This method parses the metadata of the open-source software packages and compares it with the dependencies already installed on the local system. It analyzes the compatibility of the open-source software packages from a static perspective, then performs dynamic behavior tests on the open-source software packages on the local system to generate a native compatibility report. The specific steps include:

[0052] S101, parse the metadata of the Kaiming software package to obtain the software package dependency data information.

[0053] By extracting and parsing the metadata file of the Kaiming software package, the various dependencies of the Kaiming package are analyzed and organized to generate package dependency data information. During metadata parsing, the Kaiming package is first decompressed, then the metadata file within the Kaiming package is obtained, and the environment dependencies of the Kaiming package are parsed based on the contents of the corresponding fields in the metadata file.

[0054] Specifically, the metadata of the Kaiming package is obtained. Based on the base, runtime, and depends fields of the metadata, the basic environment dependencies, special environment runtime dependencies, and package dependencies of the Kaiming package are read to obtain the package dependency data information.

[0055] After decompressing the Kaiming package and obtaining its metadata, the base, runtime, and depends fields are used to read the basic environment dependencies, special environment runtime dependencies, and package dependencies of the Kaiming package, respectively. `base` represents the basic environment required for the Kaiming application to run, for example: `base:stable:top.openkylin.base / 1.0.0`, where `top.openkylin.base` represents the base package to be depended on, and `1.0.0` represents the version of that base package. `runtime` represents the runtime environment used by the Kaiming application, for example: `runtime:stable:top.openkylin.ukui / 1.0.0`, where `top.openkylin.ukui` represents the runtime package to be depended on, and `1.0.0` represents the version of that package. `depends` is a list of packages that the Kaiming application depends on, for example:

[0056]

[0057] The openkylin.extra-cmake-modules file represents the packages that need to be used, and 5.92.0 represents the version of that package.

[0058] S102, Scan the local system, perform static dependency analysis on the local system based on the software package dependency data information, and obtain static dependency pass information.

[0059] The system scans the local system to obtain the currently installed components or existing dependencies. It compares the dependencies in the current system with the dependencies of the software packages to analyze whether the dependencies required by the open-source packages can be met by the local system. That is, it determines the number of dependencies required by the open-source packages in the local system, and then analyzes whether the open-source packages can be supported or run smoothly on the local system.

[0060] Specifically, the system scans the local machine to obtain the list of base dependencies, runtime dependencies, and depend dependencies already installed on the local machine. This list is then compared with the package dependency data to determine the number of dependencies present in the package dependency data on the local machine, thus obtaining static dependency information.

[0061] The commands `kaiming list --kind=base`, `kaiming list --kind=runtime`, and `kaiming list --kind=depend` can be used to retrieve the list of installed base dependencies, runtime dependencies, and depend dependencies on the local system. These lists are then compared with the base environment dependencies, runtime dependencies, and dependencies in the package dependency data to analyze the number of dependencies required by the open-source packages on the local system, generating static dependency information. This static dependency information reflects the proportion of open-source packages that the local system can satisfy, as well as any missing critical dependencies or issues.

[0062] S103, Perform dynamic behavior testing on the Kaiming software package and obtain dynamic test pass information.

[0063] Dynamic behavior testing involves installing, running, and uninstalling the open-source software package within an isolated sandbox. This verifies the package's performance through actual operation and captures runtime exceptions via system call monitoring. The process involves installing the package on the local system and generating installation behavior test results. If installation is successful, the package is run, and runtime behavior test results are generated. Then, the package is uninstalled, and uninstallation behavior test results are generated. If installation fails, the package installation test is marked as failed. The dynamic test pass information for the open-source software package is generated using the installation, runtime, and uninstallation behavior test results.

[0064] For example, software packages can be installed, run, and uninstalled using command lines. The installation process for the open-source package org.kde.kcalc is as follows: The package is installed using the command `sudo kaiming install org.kde.kcalc`. The installation command is checked for errors; if successful, the test result is marked as successful; otherwise, it is marked as failed. The package is run using the command `kaiming run org.kde.kcalc`. The run command is checked for errors; if successful, the test result is marked as successful; otherwise, it is marked as failed. The package is uninstalled using the command `kaiming uninstall org.kde.kcalc`. The uninstallation command is checked for errors; if successful, the test result is marked as successful; otherwise, it is marked as failed.

[0065] S104 generates a native compatibility report for the open-source software package based on static dependency pass information and dynamic test pass information.

[0066] Using static dependency pass information (representing static test results) and dynamic test pass information (representing dynamic test results), the native compatibility of the Kaiming package is evaluated from the perspectives of static dependencies and dynamic behavior, respectively. Test reports containing both static and dynamic results are generated. These reports mainly include test objectives, test scope, test environment configuration, and test results, demonstrating the compatibility of the Kaiming package on the local system and providing a reference for developers during debugging. This is particularly important for newly developed Kaiming packages, as it ensures their successful installation, operation, and uninstallation on the local system. An example of a native compatibility report for a Kaiming package is shown in Table 1.

[0067] Table 1. Native Compatibility Report of Kaiming Software Package

[0068]

[0069] This embodiment utilizes a two-layer architecture of "application container + metadata" for open-source software packages. By extracting the metadata layer, it performs static dependency analysis at three levels: base, runtime, and depend. It also conducts dynamic testing throughout the entire lifecycle of installation, startup, and uninstallation. This comprehensive approach, covering both static and dynamic aspects, fully covers the system call layer of open-source software packages. It can detect runtime issues such as SELinux policy conflicts missed by static analysis, improving the efficiency of dependency analysis for open-source packages and reducing false positives. Furthermore, it can be executed through automated test scripts without manual intervention, filling a gap in testing tools for open-source package formats. This injects standardized quality assurance methods into the domestic operating system ecosystem and promotes improved delivery efficiency of domestically developed software.

[0070] Example 2

[0071] Figure 2 This is a flowchart of a method for verifying the migration compatibility of a Kaiming software package according to Embodiment 2 of the present invention. This embodiment parses the metadata of the Kaiming software package, then upgrades the baseline system version of the local system. It compares the dependencies already installed on the upgraded target system with the dependencies of the Kaiming software package to analyze the compatibility of the Kaiming software package on the upgraded target system from a static perspective. Then, it performs dynamic behavior testing of the Kaiming software package on the target system to obtain a migration compatibility report for the Kaiming software package between different system versions. Specifically, it includes the following steps:

[0072] S201, parse the metadata of the Kaiming software package to obtain the software package dependency data information.

[0073] By extracting and parsing the metadata file of the Kaiming package, the base environment dependency, special environment runtime dependency and package dependency of the Kaiming package are read from the base, runtime and dependencies fields respectively. The specific parsing process is the same as the parsing process in S101 of Example 1, and will not be repeated here.

[0074] S202, upgrade the local system to the baseline system version, scan the upgraded target system version, perform static dependency analysis on the target system based on package dependency data, and obtain the static dependency pass information after the upgrade.

[0075] The operating system of the local system is upgraded (e.g., the operating system version is upgraded from 1.0 to 2.0). The upgraded target system is scanned to obtain the base dependency list, runtime dependency list, and depend dependency list of the local system. Based on the components or existing dependencies installed in the upgraded target system, the software package dependency data is compared with the software package dependency data. The number of dependencies in the software package dependency data in the upgraded target system is analyzed. It is analyzed whether the dependencies required by the open package can be satisfied by the upgraded target system, that is, the number of dependencies required by the open package in the upgraded target system. Then, it is analyzed whether the open package can be supported or run smoothly in the upgraded target system. The upgraded static dependency pass information is generated. The specific process is the same as S102 in Example 1, and will not be repeated.

[0076] S203, In the upgraded target system, perform dynamic behavior testing on the Kaiming software package and obtain information indicating that the dynamic test passed after the upgrade.

[0077] In the upgraded target system, dynamic behavior testing is used to install, run, and uninstall the Kaiming package in an isolated sandbox. The operation of the Kaiming package is verified through actual dynamic operations in the upgraded target system, and runtime anomalies are captured through system call monitoring. The installation, running, and uninstallation operations of the Kaiming package are performed in the upgraded target system. Using the installation behavior test results, running behavior test results, and uninstallation behavior test results, information indicating that the upgraded dynamic test of the Kaiming package has passed is generated. The specific method is the same as S103 in Example 1 and will not be repeated here.

[0078] S204 generates an open-source software package migration compatibility report based on the static dependency pass information and the dynamic test pass information after the upgrade.

[0079] Using the static dependency pass information and dynamic behavior test pass information obtained from static dependency analysis and dynamic behavior testing on the upgraded target system, the compatibility of Kaiming packages on the target system after the system baseline version upgrade is evaluated. A test report containing both static and dynamic results is generated. The test report reflects the compatibility changes of static dependencies and dynamic behavior of Kaiming packages after the operating system version upgrade, as well as the support capabilities for different system versions, demonstrating the migration compatibility of Kaiming packages between different system versions. Finally, a Kaiming package migration compatibility report is formed. An example of a Kaiming package migration compatibility report is shown in Table 2.

[0080] Table 2. Kaiming Software Package Migration Compatibility Report

[0081]

[0082] This embodiment performs compatibility testing of the OpenMind package on the system after the baseline version is upgraded. By combining static and dynamic perspectives, it verifies the compatibility of the OpenMind package in the system migration scenario by combining static dependency satisfaction metric evaluation with dynamic functional consistency verification after migration. This greatly shortens the migration time of the OpenMind package across domestic OSes, reduces the workload required for manual adaptation, and allows developers to perform automated dependency adaptation based on the compatibility report, reducing secondary development costs and improving the success rate of OpenMind package migration verification.

[0083] Example 3

[0084] Figure 3 This is a flowchart of a method for detecting the upgrade compatibility of open-source software packages according to Embodiment 3 of the present invention. This embodiment uses the API interface provided by the ELF file through the metadata parsing of the open-source package to compare the changes in the ELF file and API interface between the new and old versions of the open-source package. At the same time, it detects the version upgrade compatibility of the open-source software package through dynamic version upgrade and downgrade operations. Specifically, it includes the following steps:

[0085] S301 parses the metadata of the Kaiming software package and the upgraded Kaiming software package respectively to obtain the API data information of the software package and the API data information of the upgraded software package.

[0086] The metadata of the Kaiming software package can be used to parse the API data provided by the package. By comparing the APIs of different versions of the Kaiming software package before and after the upgrade, the API data information of the package before the upgrade and the API data information of the package after the upgrade can be generated, which can be used to analyze the API changes and differences between different versions of the Kaiming software package.

[0087] Specifically, the metadata of the Kaiming software package and the upgraded Kaiming software package are obtained separately. The version information is read according to the version field of the metadata, and all ELF files are scanned and saved as the current version ELF file list and the upgraded version ELF file list, respectively.

[0088] By obtaining the metadata layer of the Kaiming software package and reading the version field, the version information of the Kaiming package can be obtained. Kaiming packages with the same package but different versions are categorized into the original Kaiming package and the upgraded version Kaiming package based on their version. The original and upgraded versions are scanned separately, and all their ELF files are extracted and saved as a current version ELF file list and an upgraded version ELF file list, respectively. For example, by decompressing the Kaiming package, the resulting ELF files are stored in the Files / Bin directory; the ELF file list can be obtained by reading the file list in this directory.

[0089] Based on the ELF file list, read the APIs provided by all ELF files and generate the package API data information for the current version and the upgraded package API data information for the upgraded version.

[0090] The process involves scanning each ELF file in the ELF file list, obtaining and summarizing all APIs provided by each ELF file, and generating API data for the current version and the upgraded version of the software package, respectively. For example, the command `readelf -s --dyn-syms / path / to / elf_file|grep 'FUNC\|GLOBAL'` can be used to scan each ELF file in both the current and upgraded ELF file lists to obtain the API information for each file. Summarizing all API information from all ELF files in the ELF file list yields the API data for the current version and the upgraded version of the software package, respectively.

[0091] S302. Based on the current version of the ELF file list and the upgraded ELF file list, as well as the package API data information and the upgraded package API data information, static change comparisons are performed to obtain static change data information.

[0092] By comparing the ELF file lists before and after the version upgrade, and by comparing the API data before and after the version upgrade, we can obtain the differences and changes between the ELF files and API interfaces before and after the Kaiming software package version upgrade, forming static change data information.

[0093] Specifically, the current version of the ELF file list is compared with the upgraded version of the ELF file list, and ELF file change data information is generated based on the differences in the ELF files.

[0094] The current version's ELF file list is compared with the upgraded version's ELF file list. The changes in ELF files after the upgrade are listed, including additions and deletions, and ELF file change data is generated.

[0095] Using the current version of the software package API data and the upgraded version's software package API data, API interface change data information is generated based on the differences in API interfaces.

[0096] Next, list the additions, modifications, and deletions of API interfaces for each identical ELF file in the upgraded version of the open source package compared to the old version. Summarize the changes to the API interfaces of all ELF files to generate API interface change data. If the upgraded open source package only shows additions to its API interfaces compared to the old version, without any modifications or deletions, then the upgraded open source package is compatible with the previous version.

[0097] Static change data information is generated based on the change data information in the ELF file and the API interface.

[0098] By summarizing the ELF file change data and API interface change data, the resulting static change data can show which ELF files have changed (added, deleted) after the Kaiming software package is upgraded compared to the old version, as well as the API interface changes (added, modified, deleted) between the same ELF files. This allows for a static analysis of the changes in the Kaiming software package, and further analysis of the compatibility changes of the Kaiming software package.

[0099] S303 utilizes the Kaiming software package and the upgraded version of the Kaiming software package to perform dynamic upgrade testing and generate dynamic test data information for version upgrades.

[0100] Dynamic upgrade tests of Kaiming packages are performed in an isolated sandbox. Upgrade commands are executed on older versions of the Kaiming packages, and downgrade commands are executed on newer versions. Based on the upgrade and downgrade results, the version upgrade compatibility of the Kaiming packages is tested through dynamic practical operations, generating dynamic version upgrade test data. For example, the `kaiming update org.kde.kcalc` command is used to upgrade the Kaiming package, and the `sudo kaiminginstall-c org.kde.kcalc` command is used to downgrade it. The success of the upgrade and downgrade operations is determined based on the command execution results returned by the system.

[0101] S304 generates an upgrade compatibility report for the Kaiming software package based on static change data and dynamic test data for version upgrades.

[0102] The obtained static change data and dynamic test data for version upgrades are summarized to generate an upgrade compatibility report for the Kaiming software package. This report reflects the API changes before and after the version upgrade, and verifies the success rate of software upgrades and downgrades through actual dynamic operations. The report includes both static and dynamic results, and mainly contains test objectives, test scope, test environment configuration, and test results. These results demonstrate the compatibility changes after the Kaiming software package version upgrade, providing developers with a reference for debugging. An example upgrade compatibility report for the Kaiming software package is shown in Table 3.

[0103] Table 3. Upgrade Compatibility Report of Kaiming Software Package

[0104]

[0105] This embodiment parses different versions of the Kaiming package using metadata, extracts ELF files from the metadata to form an ELF file list, compares the changes in ELF files before and after the version upgrade, and then reads the API interface information of each ELF file one by one to compare the API interface changes between the same ELF files before and after the version upgrade, generating static change data. Then, dynamic Kaiming package version upgrade and downgrade operations are performed. Combining the static change data and dynamic test data, an upgrade compatibility report for the Kaiming package is generated. By comparing API interface change differences from a static perspective, the interface changes of the Kaiming package before and after the version upgrade are identified. Combined with dynamic upgrade and downgrade tests, a version upgrade compatibility risk report is generated from multiple dimensions. Symbol table parsing of the ELF file list for change analysis, interface call chain tracing for API interface change analysis, and dynamic upgrade / downgrade operations and automated rollback mechanisms are used to test and analyze the compatibility of the Kaiming package before and after the version upgrade. This method has high accuracy in detecting API changes during version upgrades, can provide early warnings of most upgrade risks caused by interface incompatibility, avoids system crashes caused by version iterations, and ensures business continuity.

[0106] Example 4

[0107] Figure 4 This is a schematic diagram of the structure of an open-source software package compatibility testing and verification device according to Embodiment 4 of the present invention. In this embodiment, the open-source software package compatibility testing and verification device includes:

[0108] The metadata analysis module 810 is used to parse the metadata of the Kaiming software package to form software package dependency data information or software package API data information;

[0109] The static testing module 820 is used to perform static dependency analysis based on package dependency data and system environment to generate static dependency pass information under the current system version, or to perform static change comparison based on package API data to generate static change data information.

[0110] The dynamic testing module 830 is used to perform dynamic behavior testing or dynamic upgrade testing on the Kaiming software package under the current system version, and generate dynamic test pass information or version upgrade dynamic test pass information;

[0111] The test report generation module 840 is used to generate a compatibility report for the Kaiming software package based on the static test results and dynamic test results.

[0112] This embodiment uses a metadata analysis module to extract and parse the metadata of the Kaiming software package and generate static dependency data or API data. A static testing module performs static comparative analysis on the dependency or API status of the software package and generates static dependency data or static API change data. A dynamic testing module performs dynamic behavior tests such as installation and upgrades on the Kaiming software package in an isolated sandbox and generates dynamic test data. A test report generation module generates a compatibility report of the Kaiming software package based on the static and dynamic test results for developers to refer to and debug. By targeting the two-layer architecture of the Kaiming software package—"application container + metadata"—the content of the metadata layer is extracted, and static dependency analysis is performed at three levels: base, runtime, and depend. Dynamic testing is also conducted throughout the entire lifecycle of installation, startup, and uninstallation, comprehensively covering the system call layer of the Kaiming software package. By combining static and dynamic perspectives, and combining static dependency satisfaction metric evaluation with dynamic functional consistency verification after migration, the compatibility of the Kaiming software package in the local system environment and in system migration scenarios is verified. Runtime issues such as SELinux policy conflicts missed by static analysis can be detected, improving the efficiency of dependency analysis for Kaiming packages, reducing false positive rates, and significantly shortening the migration time of Kaiming software packages across different domestic OSes. It reduces the workload required for manual adaptation; it compares the changes in ELF files of open-source packages before and after version upgrades by comparing the ELF file list, and then reads the API interface information of each ELF file one by one to compare the API interface changes between the same ELF files before and after version upgrades. Then, it performs dynamic open-source package version upgrade and downgrade operations. By comparing the differences in API interface changes from a static perspective, it identifies the interface changes of open-source packages before and after version upgrades. Combined with dynamic upgrade and downgrade testing, it generates a version upgrade compatibility risk report from multiple dimensions, which can provide early warning of most upgrade risks caused by interface incompatibility and avoid system crashes and other problems caused by version iteration. At the same time, it can be executed by automated test scripts without human intervention, filling the gap in open-source package format testing tools.

[0113] The open-source software package compatibility testing and verification device provided in this embodiment of the invention can execute the open-source software package compatibility testing and verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0114] Example 5

[0115] Figure 5 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 5 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 5 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0116] like Figure 5 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0117] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0118] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0119] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0120] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0121] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 5 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0122] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the open software package compatibility detection and verification method provided in the embodiments of the present invention.

[0123] Example 6

[0124] Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the open-source software package compatibility detection and verification method provided in the above embodiments.

[0125] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0126] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0127] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0128] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0129] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. An open software package native compatibility detection method, characterized in that, The method comprises the following steps: S101, parsing the metadata of the open source software package to obtain software package dependency data information; S102, scanning the local system to perform static dependency analysis on the local system according to the software package dependency data information to obtain static dependency passing information; S103, performing dynamic behavior testing on the open source software package to obtain dynamic testing passing information; S104, generating an open source software package local compatibility report according to the static dependency passing information and the dynamic testing passing information.

2. The method of claim 1, wherein, The S101 comprises the following steps: Obtaining the metadata of the open source software package, reading the base environment dependency, special environment runtime dependency and software package dependency of the open source software package according to the base, runtime and depends fields of the metadata to obtain the software package dependency data information.

3. The method of claim 1, wherein, The S102 comprises the following steps: Scanning the local system to obtain the installed base dependency list, runtime dependency list and depend dependency list of the local system, and comparing the lists with the software package dependency data information to determine the number of dependencies contained in the software package dependency data information in the local system to obtain the static dependency passing information.

4. An open source software package migration compatibility verification method, characterized in that: S201, parsing the metadata of the open source software package to obtain software package dependency data information; S202, performing baseline system version upgrade on the local system, scanning the upgraded target system version, performing static dependency analysis on the target system according to the software package dependency data information to obtain post-upgrade static dependency passing information; S203, performing dynamic behavior testing on the open source software package in the upgraded target system to obtain post-upgrade dynamic testing passing information; S204, generating an open source software package migration compatibility report according to the post-upgrade static dependency passing information and the post-upgrade dynamic testing passing information.

5. An open source software package upgrade compatibility detection method, characterized in that: S301, respectively parsing the metadata of the open source software package and the open source software package after version upgrade to obtain software package API data information and post-upgrade software package API data information; S302, respectively performing static change comparison according to the current version ELF file list and the post-upgrade ELF file list, and according to the software package API data information and the post-upgrade software package API data information to obtain static change data information; S303, performing dynamic upgrade testing on the open source software package and the open source software package after version upgrade to generate version upgrade dynamic testing data information; S304, generating an open source software package upgrade compatibility report according to the static change data information and the version upgrade dynamic testing data information.

6. The method of claim 5, wherein, The S301 comprises the following steps: Respectively obtaining the metadata of the open source software package and the open source software package after version upgrade, reading the version information according to the version field of the metadata, and scanning all ELF files to respectively save them as the current version ELF file list and the post-upgrade version ELF file list; According to the API provided by the ELF file list reading all ELF files, the current version of the software package API data information and the upgraded version of the upgraded software package API data information are formed respectively.

7. The method of claim 5, wherein, The S302 comprises: By comparing the current version ELF file list and the upgraded version ELF file list, the ELF file change data information is generated according to the ELF file difference; By using the current version of the software package API data and the upgraded version of the upgraded software package API data, the API interface change data information is generated according to the API interface difference; According to the ELF file change data information and the API interface change data information, the static change data information is generated.

8. An open package compatibility detection verification apparatus, characterized by comprising: Comprise: The metadata analysis module is used for analyzing the metadata of the open software package to form the software package dependency data information or the software package API data information; The static test module is used for performing static dependency analysis according to the software package dependency data information and the system environment to form the static dependency pass information under the current system version, or performing static change comparison according to the software package API data to generate the static change data information; The dynamic test module is used for performing dynamic behavior test or dynamic upgrade test on the open software package under the current system version to generate the dynamic test pass information or the version upgrade dynamic test pass information; The detection report generation module is used for generating the compatibility report of the open software package according to the static test result and the dynamic test result.

9. An electronic device, comprising: The electronic device comprises: One or more processors; Storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the open software package compatibility detection verification method as claimed in any one of claims 1-7.

10. A storage medium containing computer executable instructions for executing the open software package compatibility detection verification method as claimed in any one of claims 1-7 when executed by a computer processor.

Images