A method and server for determining redundant dependencies of a software package

Abstract

Embodiments of the present application provide a method and a server for determining redundant dependencies of a software package. The method comprises: determining a target software package; the target software package is a software package whose redundant dependency relationship is to be determined; obtaining, based on a detector, file data actually accessed by the target software package during runtime from one or more running environments; the file data comprises a file path and a file name; the running environment is an operating system and a hardware environment that meet the requirement that the target software package can operate normally; and determining redundant dependencies of the target software package based on the actually accessed file data. The scheme can directly obtain, based on the detector, files accessed by the target software package during the entire running process on each running environment, and then determine the files that are actually required during runtime, without human intervention, thereby improving the efficiency of determining redundant dependencies while ensuring accuracy.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a method and server for determining software package redundancy dependencies. Background Technology

[0002] Currently, mainstream Linux operating systems primarily employ two package manager formats: Red Hat PackageManager (RPM) and Debian (DEB). Due to the open-source nature of the system, many people in the Linux community participate in software development and maintenance, leading to a continuous increase in the size and number of software packages. This results in a large number of redundant dependencies, impacting application performance. Therefore, it is necessary to manage package dependencies and remove redundant dependencies promptly and accurately.

[0003] Existing dependency management methods involve manually specifying or analyzing the source code of software packages to determine their dependencies, which are then added to the package's documentation (such as .spec files) for management. Current methods for identifying redundant dependencies typically involve developers manually inspecting the package's source code and dependency management files (documentation files) to identify and remove obvious redundant dependencies. However, due to varying package sizes, manually eliminating redundant dependencies is time-consuming for large projects or complex dependency networks, and is easily influenced by subjective judgment, resulting in low efficiency and accuracy in identifying redundant dependencies.

[0004] Therefore, how to improve the efficiency of identifying redundant dependencies while ensuring accuracy is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and server for determining redundant dependencies in software packages. This method accurately identifies the truly necessary runtime dependencies without requiring manual intervention, thus improving the efficiency of redundant dependency determination.

[0006] Firstly, embodiments of this application provide a method for determining redundant dependencies of a software package, comprising: determining a target software package; the target software package being a software package whose redundant dependencies are to be determined; obtaining, based on a detector, file data actually accessed by the target software package during runtime from one or more runtime environments; the file data including file paths and file names; the runtime environment being an operating system and hardware environment that enables the target software package to run normally; and determining the redundant dependencies of the target software package based on the actually accessed file data. Thus, embodiments of this application directly obtain the files accessed by the target software package throughout its runtime in various runtime environments based on a detector, thereby identifying the truly needed runtime dependencies, avoiding errors in redundant dependency judgment caused by the software implementation development language, and improving the accuracy of determining redundant dependencies.

[0007] In one possible implementation, before obtaining the file data actually accessed by the target software package at runtime from one or more runtime environments based on the detector, the method further includes: issuing a detection configuration to the detector; the detection configuration is used to indicate that the target software package is the target of the detector. Thus, this embodiment of the application introduces a detection configuration, which ensures that the detector and the target software package determined by the dependency analysis server are the same, improving the accuracy of determining redundant dependencies.

[0008] In one possible implementation, obtaining file data actually accessed during the execution of the target software package from one or more runtime environments includes: triggering a detector to obtain system call data of the target software package during runtime in one or more runtime environments based on a detection configuration; obtaining the system call data from the detector; and generating file data actually accessed by the target software package based on the system call data. Thus, this embodiment of the application introduces multiple runtime environments, avoiding errors in individual environments, thereby more accurately identifying software dependencies and improving the accuracy of determining redundant dependencies.

[0009] In one possible implementation, the trigger detector, based on the detection configuration, obtains system call data of the target software package during runtime under one or more operating environments. This includes: acquiring system calls of the target software package during runtime using a system monitoring tool and obtaining the corresponding system call data. Thus, this embodiment of the application introduces a system monitoring tool built into the Linux system to monitor system calls, eliminating the need to introduce new external tools, thereby saving detection time, avoiding uncertainties from external software, and improving the efficiency and accuracy of determining redundant dependencies.

[0010] In one possible implementation, the system monitoring tools include: an efficient virtual machine (extended Berkeley Packet Filter, eBPF) monitoring tool and / or a tracing mechanism (kprobe) monitoring tool. Thus, this embodiment of the application introduces system-provided tools such as eBPF monitoring tools and tracing mechanism monitoring tools, eliminating the need to introduce new external tools and improving the efficiency and accuracy of identifying redundant dependencies.

[0011] In one possible implementation, the system calls include the `open` system call and the `execve` system call. Thus, this embodiment of the application introduces the `open` and `execve` system calls to determine the file data actually accessed by the target software package, thereby eliminating reliance on the actual development language of the software and improving the applicability and accuracy of identifying redundant dependencies.

[0012] In one possible implementation, determining the redundant dependencies of the target software package based on actually accessed file data includes: summarizing the actually accessed file data obtained from various runtime environments; comparing the actually accessed file data with the specification file corresponding to the target software package to determine the redundant dependencies of the target software package; the specification file is used to record all dependencies of the target software package. Thus, this embodiment of the application, through the summary analysis of multi-environment detection results, avoids errors in individual environments, thereby more accurately identifying software dependencies and improving the accuracy of determining redundant dependencies.

[0013] In one possible implementation, the method further includes: generating a redundancy dependency report based on the actually accessed file data; the redundancy dependency report is used to record all redundant dependencies of the target software package. Thus, this embodiment of the application introduces a redundancy dependency report, storing or presenting the redundant dependencies of the target software package to the user in the form of a report, thereby improving data readability.

[0014] In one possible implementation, obtaining file data actually accessed by the target software package at runtime from one or more runtime environments includes: triggering a detector to obtain system call data of the target software package at runtime in one or more runtime environments based on a detection configuration, and generating file data actually accessed by the target software package through parsing; and directly obtaining file data from the detector. This application introduces multiple runtime environments to avoid errors in individual environments, thereby more accurately identifying software dependencies and improving the accuracy of determining redundant dependencies. Secondly, this application provides an apparatus for determining software package redundancy dependencies, including:

[0015] The determination module is used to determine the target software package; the target software package is the software package whose redundant dependencies are to be determined.

[0016] The acquisition module is used to acquire, based on the detector, the file data actually accessed by the target software package at runtime from one or more runtime environments; the file data includes file path and file name; the runtime environment is the operating system and hardware environment that enables the target software package to run normally;

[0017] The determination module is used to determine redundant dependencies of the target software package based on the actual file data accessed.

[0018] Thirdly, embodiments of this application provide a server, characterized in that it includes:

[0019] Memory and processor are coupled;

[0020] Memory, used to store computer programs;

[0021] A processor, used to implement the steps described above for determining software package redundancy dependencies when executing a computer program.

[0022] Fourthly, embodiments of this application provide a calculator-readable storage medium having a computer program / instruction stored thereon, which, when run on a computer, causes a server to perform the steps of the method for determining software package redundancy dependencies described above.

[0023] Fifthly, embodiments of this application also provide a computer program product, which includes a computer program; when the computer program runs on a server, it performs the steps of the method for determining software package redundancy dependencies described above. Attached Figure Description

[0024] Figure 1 A flowchart illustrating a method for determining software package redundancy dependencies, provided in an embodiment of this application;

[0025] Figure 2 A redundancy dependency analysis architecture diagram provided for embodiments of this application;

[0026] Figure 3 A schematic diagram of a detector logic unit provided in an embodiment of this application;

[0027] Figure 4 This is a schematic diagram of a detector execution flow provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram illustrating a dependency analysis server analyzing redundant dependencies, provided as an embodiment of this application;

[0029] Figure 6 A schematic diagram of a dependency analysis server execution flow provided for an embodiment of this application;

[0030] Figure 7A schematic diagram of a device for determining software package redundancy dependencies provided in an embodiment of this application;

[0031] Figure 8 This is a schematic diagram of a server structure provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0033] In the description of the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0034] In the description of the embodiments in this application, the term "and / or" is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, and A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple terminals refer to two or more terminals.

[0035] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0036] The following explanations cover some of the terms used in this embodiment. It should be noted that these explanations are for the convenience of those skilled in the art and are not intended to limit the scope of protection claimed by this invention.

[0037] eBPF is a technology in the Linux kernel that allows developers to execute custom code within the kernel to achieve applications such as efficient network traffic analysis, performance monitoring, and security auditing. The goal of eBPF is to provide a lightweight, low-overhead way to extend the functionality of the Linux kernel, thereby enabling more applications to leverage the foundation of the Linux ecosystem.

[0038] Kprobe is a programmable tracing tool provided by the Linux operating system kernel for dynamic tracing, debugging, and performance analysis during kernel function execution. It allows developers to insert probes anywhere in the kernel code to execute custom code at those locations. These probes can be used to collect performance data, log time, modify system behavior, and more.

[0039] RPM was originally developed by Red Hat and is now used by many Linux distributions. It uses .rpm files as the file extension for packages.

[0040] DEB is the package management system used by Debian distributions and their derivatives (such as Ubuntu). It uses .deb files as the file extension for packages.

[0041] As mentioned earlier, existing methods for identifying redundant dependencies in software packages suffer from inefficiency and insufficient accuracy. Specifically, due to the open-source nature of systems, more people participate in software development and maintenance, leading to a continuous increase in the size and number of software packages and generating a large number of redundant dependencies. Existing methods for removing redundant dependencies fall into two categories. One relies on developers manually checking the package source code and dependency management files to see if there are duplicate dependencies, multiple dependencies providing the same functionality, or old, unused versions of dependencies. Predictably, this method is extremely labor-intensive, prone to human error, and results in inaccurate and inefficient identification of redundant dependencies. The other method relies on static code analysis tools to identify redundant dependencies, but these tools often fail to understand the code's context and vary in their support for programming languages ​​and detection rules, similarly leading to inaccurate identification of redundant dependencies.

[0042] To address the aforementioned issues, this application provides a method for determining redundant dependencies of a software package, comprising: first, identifying a target software package, wherein the target software package is the software package whose redundant dependencies are to be determined; then, based on a detector, obtaining file data actually accessed by the target software package during runtime from one or more runtime environments; wherein the file data includes file paths and file names, and the runtime environment is an operating system and hardware environment that enables the target software package to run normally; and finally, determining the redundant dependencies of the target software package based on the actually accessed file data.

[0043] In this way, by directly acquiring the files accessed by the target software package in each operating environment during the entire operation process based on the detector, the truly needed runtime dependencies can be identified, avoiding the phenomenon of incorrect judgment of redundant dependencies caused by the software implementation development language, and improving the accuracy of identifying redundant dependencies.

[0044] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0045] Figure 1 A flowchart illustrating a method for determining software package redundancy dependencies, provided as an embodiment of this application. (In conjunction with...) Figure 1 As shown in the embodiments of this application, a method for determining software package redundancy dependencies may include:

[0046] S101: Identify the target software package; the target software package is the software package whose redundant dependencies need to be determined.

[0047] In practical applications, modern software typically consists of multiple modules or components that need to work together to achieve specific or basic functions. Some software relies on other software packages or libraries during its build process to compile and link the program, generating executable files or libraries; these dependencies are usually called build-time dependencies. Additionally, some software depends on specific hardware resources or system services, such as databases, graphical interface libraries, audio players, etc. These resources or services can be implemented through dependencies without needing to be directly implemented in the program; these dependencies are usually called runtime dependencies or installation-time dependencies. The scope and severity of the impact of redundancy between build-time and runtime dependencies differ significantly. Redundancy in build-time dependencies simply involves installing more software packages in the build environment, without much impact. Runtime dependencies, however, have a greater impact on the performance and reliability of the software package. Therefore, this application primarily focuses on identifying redundant runtime dependencies and proposes an automated software dependency analysis method independent of the software implementation development language. This method uses a dependency analysis server combined with a detector to summarize and analyze the files actually accessed by the software package during installation and runtime, thereby determining the redundant dependencies of the software package. Specifically, the dependency analysis server first needs to identify the target software packages, i.e., the packages that require redundant dependency screening (to determine redundant dependencies). For example, if a computer's operating environment contains software packages A, B, and C, and the dependency analysis server is associated with that computer, these three packages will be displayed in the server's software list. The user can then select one of them using the mouse pointer or by sending a command. The dependency analysis server will then designate the selected package as the target package. If package A is selected, the dependency analysis server will use package A as the target package and determine redundant dependencies for package A. This improves the flexibility and accuracy of software package redundancy dependency analysis.

[0048] Furthermore, since the content of information transmitted to the detector is not entirely the same, the embodiments of this application can describe one possible content of transmission.

[0049] In one scenario, before retrieving file data actually accessed at runtime by the target software package from one or more runtime environments based on a detector, the method further includes:

[0050] Send detection configuration to the detector;

[0051] The detection configuration is used to indicate which target software package to use as the target of the detector.

[0052] In practical applications, dependency analysis servers need to be used in conjunction with probes. The probes, deployed in the actual production environment, probe the entire runtime process of a target software package based on the requirements issued by the dependency analysis server. Therefore, they first need to identify the same target software package as the dependency analysis server. Specifically, after identifying the target software package, the dependency analysis server sends a probe configuration containing indication information about the target software package to the probe. The probe then parses this probe configuration to identify the target software package that matches the one identified by the dependency analysis server. In other words, the probe configuration indicates that the target software package should be the probe's target. It's important to note that the probe configuration can also include the content to be probed and the system monitoring tools to be used. This ensures that the target software package identified by the dependency analysis server and the probe is consistent, improving the probe's detection accuracy and thus improving the accuracy of software package redundancy dependency analysis.

[0053] S102: Based on the detector, obtain the actual file data accessed by the target software package during runtime from one or more operating environments; the file data includes file path and file name; the operating environment is the operating system and hardware environment that enables the target software package to run normally.

[0054] In practical applications, Figure 2 This is a diagram illustrating a redundancy dependency analysis architecture provided in an embodiment of this application. (Combined with...) Figure 2As shown, the detectors are deployed in an actual production environment. To avoid judgment errors in individual environments and improve the accuracy of determining redundant dependencies, this embodiment can deploy detectors in multiple environments (Environment A, Environment B, and Environment C). After determining the target software package, the dependency analysis server issues detection configurations to each detector, enabling each detector to determine the target software package based on the detection configurations and to detect the target software package, obtaining the file data actually accessed by the target software package during its entire operation in Environment A, Environment B, and Environment C. The operating environment refers to the operating system and hardware environment that allows the target software package to run normally. The detectors use the file data actually accessed by the target software package during its entire operation in Environment A, Environment B, and Environment C as detection data and report it to the dependency analysis server for analysis. That is, the dependency analysis server can obtain the file data actually accessed by the target software package in Environment A, Environment B, and Environment C during its entire operation from the detectors. It is understood that in order to parse the actual dependencies of the target software package from the file data, the file data should contain file paths and file names, etc. Additionally, it's important to note that environments A, B, and C are merely examples of multiple environments; environments D, E, and F, among others, could also exist, but this is not a limitation here. By deploying detectors in multiple environments and analyzing the results from these multiple environments, errors in individual environments can be avoided, leading to more accurate identification of software dependencies and improved accuracy in determining redundant dependencies.

[0055] Furthermore, since the methods by which the detector generates the file data actually accessed by the target software package are not entirely the same, this application embodiment can describe one possible generation method.

[0056] In one scenario, S102: Based on the detector, obtain the file data actually accessed by the target software package at runtime from one or more runtime environments, which may specifically include:

[0057] The trigger detector obtains system call data of the target software package during runtime in one or more operating environments based on the detection configuration.

[0058] Obtain system call data from the detector;

[0059] Generate the file data actually accessed by the target software package based on system call data.

[0060] In practical applications, the dependency analysis server sends detection configurations to the detectors and triggers the detectors' detection process for the target software package. System calls are an interface provided by the operating system to applications for accessing services and resources provided by the operating system. Applications can send requests to the operating system through system calls to perform privileged operations, access hardware devices, manage processes and files, etc. Therefore, system calls may be involved in the installation and operation of software packages, and system calls can directly map the dependencies of the software package with other software and libraries during installation and operation. Therefore, this application embodiment determines the redundant dependencies of the target software package by obtaining system call data during the installation and operation of the target software package. Specifically, continuing with the example of deploying detectors in environments A, B, and C, after the detector's detection process is triggered, the target software package is installed and run on environments A, B, and C respectively. The detectors deployed in each environment detect and obtain the system call data involved in the entire operation of the target software package in each environment and send it to the dependency analysis server. The dependency analysis server obtains the system call data from the detectors and then parses the system call data to obtain the paths and filenames of files accessed by the application, thus generating the file data actually accessed by the target software package during the entire operation. In this way, by deploying detectors in multiple environments and analyzing the results from multiple environments, errors in individual environments can be avoided, thereby more accurately identifying software dependencies and improving the accuracy of determining redundant dependencies.

[0061] Furthermore, since the entities that parse system call data are not all the same, this application embodiment can describe one possible parsing entity.

[0062] In one scenario, file data actually accessed by the target software package at runtime is obtained from one or more runtime environments, including:

[0063] The trigger detector, based on the detection configuration, obtains the system call data of the target software package during runtime in one or more operating environments, and generates the file data actually accessed by the target software package by parsing it.

[0064] File data is obtained directly from the detector.

[0065] In practical applications, as discussed above, system calls may be involved during the installation and operation of software packages, and these system calls can directly map the dependencies of the software package with other software and libraries during installation and operation. Therefore, this embodiment of the application determines the redundant dependencies of the target software package by obtaining system call data during the installation and operation of the target software package. Furthermore, to reduce the parsing burden on the dependency analysis server, this embodiment of the application can use a detector to perform the parsing action. Specifically, continuing with the example of deploying detectors in environments A, B, and C, when the detector's detection process is triggered, the target software package is installed and run on environments A, B, and C, respectively. The detectors deployed in each environment detect and obtain the system call data involved in the entire operation of the target software package in each environment, and parse the parameters of the system call data to obtain the paths and filenames of the files accessed by the application, i.e., generating the file data actually accessed by the target software package during the entire operation, and reporting it to the dependency analysis server. Finally, the dependency analysis server obtains the file data actually accessed by the target software package during operation in each environment from the detectors reported by the server. In this way, by deploying detectors in multiple environments and analyzing the results from multiple environments, errors in individual environments can be avoided, thereby more accurately identifying software dependencies and improving the accuracy of determining redundant dependencies. Furthermore, because the detectors perform file parsing, the dependency analysis server directly obtains the file data used for analysis, reducing the parsing burden on the dependency analysis server and improving the efficiency of determining redundant dependencies.

[0066] Furthermore, since the detectors obtain system call data in different ways, this application embodiment can describe one possible method of obtaining the data.

[0067] In one scenario, the trigger detector, based on a detection configuration, obtains system call data of the target software package during runtime in one or more operating environments, including:

[0068] The system calls of the target software package during runtime are obtained using system monitoring tools, and the corresponding system call data is obtained.

[0069] In practical applications, the probe can obtain system call data of the target software package throughout its operation based on the operating system's built-in system monitoring tools. Specifically, the dependency analysis server can specify the system monitoring tools that the probe can invoke in the probe configuration sent to the probe. After the probe is triggered, the probe configuration is parsed to determine the system monitoring tool, and this tool is used to probe the system calls of the target software package throughout its operation, obtaining the corresponding system call data. In this way, monitoring the system calls of the target software package based on the system's built-in monitoring tools eliminates the need to introduce new external tools, thus saving probe time, avoiding uncertainties from external software, and improving the efficiency and accuracy of identifying redundant dependencies.

[0070] Furthermore, since the system monitoring tools used are not entirely the same, this application embodiment can describe one possible tool.

[0071] In one scenario, the system monitoring tools include: the eBPF monitoring tool and / or the kprobe monitoring tool.

[0072] In practical applications, as mentioned above, the dependency analysis server can specify the system monitoring tools that the detector can invoke in the detection configuration sent to the detector. eBPF allows developers to execute custom code in the kernel to achieve efficient network traffic analysis, performance monitoring, and security auditing. Kprobe is a programmable tracing tool provided by the Linux operating system kernel for dynamic tracing, debugging, and performance analysis during kernel function execution. Therefore, in this embodiment, the detector can monitor the system calls of the target software package during runtime based on the monitoring functions of the built-in eBPF monitoring tool and / or the kprobe monitoring tool in the Linux operating system. It is understood that the detector can also monitor the system calls of the target software package and obtain corresponding system call data based on other system monitoring tools, such as top, strace, and lsof. Thus, monitoring the system calls of the target software package based on the system's built-in monitoring tools eliminates the need to introduce new external tools, saving detection time, avoiding uncertainties from external software, and improving the efficiency and accuracy of identifying redundant dependencies.

[0073] Figure 3 This is a schematic diagram of a detector logic unit provided in an embodiment of this application. (In conjunction with...) Figure 3As shown, the software package is installed and run in user space, while a probe detects the file data actually accessed by the software throughout its operation. Specifically, since the files accessed by the software process are mapped in kernel-mode system calls, the probe can monitor the target software package's system calls using kernel-mode eBPF monitoring tools and / or kprobe monitoring tools. The probe then parses the parameters of these system calls to obtain the paths and filenames of the files being accessed by the application. This eliminates the need to introduce new external tools, saving detection time, avoiding uncertainties from external software, and thus improving the efficiency and accuracy of identifying redundant dependencies.

[0074] Furthermore, since the system calls being monitored are not all the same, this application embodiment can be used to describe one possible monitoring target.

[0075] In one scenario, system calls include the open system call and the execve system call.

[0076] In practical applications, combining the above, eBPF monitoring tools and / or kprobe monitoring tools can monitor system calls such as `open()` and `execve()`. The `open()` system call is used to open files, while the `execve()` system call is used to execute the application in a new process context. Thus, by monitoring the `open` and `execve` system calls, the obtained system call data can map the file paths and filenames accessed by the target software package throughout its execution, thereby identifying redundant dependencies of the target software package and improving the accuracy of redundant dependency identification.

[0077] In conclusion, Figure 4 This is a schematic diagram illustrating the execution flow of a detector according to an embodiment of this application. (In conjunction with...) Figure 4 As shown, the process begins with the detector receiving the probe configuration from the dependency analysis server. By parsing the configuration, it identifies the target software package and the necessary monitoring tools. Then, it uses eBPF and / or kprobe monitoring tools to probe system calls made by the software process to access files, generating corresponding probe data (the actual file data accessed by the target software package during its execution). Finally, the probe data is reported to the dependency analysis server, thus completing the entire probe process for the target software package. In this way, the cooperation between the detector and the dependency analysis server improves the efficiency and accuracy of identifying redundant dependencies.

[0078] S103: Determine redundant dependencies of the target software package based on the actual accessed file data.

[0079] In practical applications, the dependency analysis server obtains the actual file data accessed by the target software package from the probe, which represents the target software package's actual dependencies. As mentioned above, existing dependency management methods determine package dependencies manually by specifying or analyzing the package's source code and adding this information to the package's specification file (e.g., a .spec file). Understandably, the specification file records all the target software package's dependencies, and the dependency analysis server can determine redundant dependencies based on the actually accessed file data. For example, consider package A, whose specification file records dependencies on packages B, C, and D. Package A runs in a production environment, is probed, and it is determined that package A accesses file x of package B and file y of package D during runtime. This data is compiled into probe data and reported to the dependency analysis server. The server can then analyze this data to determine that package A actually depends on packages B and D, and that the dependency relationship between package A and package C recorded in the specification file is a redundant dependency. Thus, determining redundant dependencies of the target software package through actual file access data improves the efficiency and accuracy of redundant dependency identification.

[0080] Furthermore, since the methods for determining the redundant dependencies of the target software package are not entirely the same, this application embodiment can describe one possible determination method.

[0081] In one scenario, S103: Determine the redundant dependencies of the target software package based on the actual accessed file data, specifically including:

[0082] Summarize the actual file access data obtained from various operating environments;

[0083] The actual accessed file data is compared with the description file corresponding to the target software package to determine the redundant dependencies of the target software package;

[0084] The documentation is used to record all the dependencies of the target software package.

[0085] In practical applications, Figure 5 This is a schematic diagram illustrating a dependency analysis server analyzing redundant dependencies, provided as an embodiment of this application. (Combined with...) Figure 5As shown, a dependency analysis server is first deployed. Users can configure the software to be probed and view the final analysis report through the dependency analysis server's interface. A probe is deployed on each environment running the software to be analyzed. The probe connects to the dependency analysis server, initiates the probe of the software to be analyzed based on the configuration issued by the analysis server, and reports the probe data (actually accessed file data) to the dependency analysis server. Assume the target software package is S, and the corresponding specification file of S states that S depends on software D1, D2, and D3. Software D1 contains three files: f1, f2, and f3; software D2 contains three files: f4, f5, and f6; and software D3 contains three files: f7, f8, and f9. Therefore, when S is deployed on environments A, B, and C, running software S will install software D1, D2, and D3 on all three environments in addition to software S itself. If the detector detects data from environment A as "S accessed f1 and f2 during operation", data from environment B as "S accessed f4 and f5 during operation", and data from environment C as "S accessed f3 and f6 during operation", and reports this data to the dependency analysis server, then the dependency analysis server aggregates the detection data reported by the detectors deployed in each operating environment (environment A, environment B, and environment C) and compares it with the specification document. It is understandable that during operation in different environments, S accessed f1, f2, f4, f5, f3, and f6. This means that the three files f7, f8, and f9 included in software D3, which S depends on, have never been accessed. Therefore, through the aggregation and comparison by the dependency analysis server, it can be determined that software S actually depends on software D1 and software D2, and software D3 is a redundant dependency. Thus, by using a simple comparison logic with the specification document, redundant dependencies are determined based on the actual file data accessed during the software package's operation, improving the accuracy and efficiency of redundant dependency determination.

[0086] Furthermore, since the data recording methods are not entirely the same, the embodiments of this application can be described for one possible determination method.

[0087] In one case, the method also includes:

[0088] Generate a redundancy dependency report based on the actual file data accessed;

[0089] The redundancy dependency report is used to record all redundant dependencies of the target software package.

[0090] In practical applications, the analysis of redundant dependencies of a target software package can be presented to users in the form of reports. Specifically, the dependency analysis server obtains probe data (actually accessed file data) reported by probes deployed in various environments. After identifying redundant dependencies through summary analysis, it can generate a redundancy dependency report corresponding to the target software package. Using the example above, if S has a redundant dependency on software D3, the generated redundancy dependency report could display the message "Software D3 is a redundant dependency of software S." This method of recording and displaying redundant dependencies in report form improves the user experience.

[0091] In conclusion, Figure 6 This is a schematic diagram illustrating the execution flow of a dependency analysis server as provided in an embodiment of this application. (In conjunction with...) Figure 6 As shown, after the dependency analysis server starts the process, it first sends detection configurations to the detectors, enabling them to initiate the detection process and report detection data. Then, the dependency analysis server receives the detection data reported by the detectors deployed in various environments, performs summary analysis, and generates a detection report (redundant dependency report) for developers to eliminate redundant dependencies in the software. Thus, this embodiment provides an automated software dependency analysis process independent of the software implementation development language. It utilizes system monitoring tools to detect system calls during software operation, counts the files actually accessed by the software in other dependencies, and thus determines the actual runtime dependencies required by the software. By summarizing and analyzing the detection results from multiple environments, it avoids errors in individual environments, thereby more accurately identifying software dependencies. Furthermore, eliminating redundant dependencies between software reduces the time and space wasted during system installation, improves the security and reliability of system operation, and reduces system maintenance work.

[0092] In summary, the embodiments of this application first determine the target software package. The target software package is the software package whose redundant dependencies need to be determined. Then, based on a detector, the actual file data accessed by the target software package during runtime is obtained from one or more runtime environments. The file data includes file paths and filenames, and the runtime environment is the operating system and hardware environment that allows the target software package to run normally. Finally, the redundant dependencies of the target software package are determined based on the actual accessed file data. In this way, by directly obtaining the files accessed by the target software package throughout its operation in various runtime environments using a detector, the truly necessary runtime dependencies can be identified without manual intervention. This also avoids errors in redundant dependency judgment caused by the software implementation language, improving the efficiency of determining redundant dependencies while ensuring accuracy.

[0093] Based on the method for determining software package redundancy dependencies provided in the above embodiments, this application also provides an apparatus for determining software package redundancy dependencies. The apparatus for determining software package redundancy dependencies will be described below with reference to embodiments and accompanying drawings.

[0094] Figure 7 This is a schematic diagram of a device for determining software package redundancy dependencies, provided as an embodiment of this application. (In conjunction with...) Figure 7 As shown, the apparatus 700 for determining software package redundancy dependencies provided in this application embodiment includes:

[0095] The first determining module 701 is used to determine the target software package; the target software package is the software package whose redundant dependencies are to be determined.

[0096] The acquisition module 702 is used to acquire, based on the detector, file data actually accessed by the target software package during runtime from one or more operating environments; the file data includes file path and file name; the operating environment is an operating system and hardware environment that enables the target software package to run normally.

[0097] The second determining module 703 is used to determine the redundant dependencies of the target software package based on the file data actually accessed.

[0098] As one implementation, the apparatus 700 for determining software package redundancy dependencies, which is used to transmit information to the detector, further includes a distribution module.

[0099] The distribution module is used to distribute the detection configuration to the detector; the detection configuration is used to indicate that the target software package should be used as the detector's detection target.

[0100] As one implementation method, regarding how to obtain the file data actually accessed during the runtime of the target software package, the aforementioned acquisition module 702 is specifically used for:

[0101] The trigger detector obtains system call data of the target software package during runtime in one or more operating environments based on the detection configuration.

[0102] Obtain system call data from the detector;

[0103] Generate the file data actually accessed by the target software package based on system call data.

[0104] The system call data obtained during the runtime of the target software package includes:

[0105] The system calls of the target software package during runtime are obtained using system monitoring tools, and the corresponding system call data is obtained.

[0106] System monitoring tools include: eBPF monitoring tool and / or kprobe monitoring tool.

[0107] System calls include the open system call and the execve system call.

[0108] As one implementation method, regarding how to determine redundant dependencies of the target software package, the second determining module 703 is specifically used for:

[0109] Summarize the actual file access data obtained from various operating environments;

[0110] The actual accessed file data is compared with the description file corresponding to the target software package to determine the redundant dependencies of the target software package;

[0111] The documentation is used to record all the dependencies of the target software package.

[0112] As one implementation, the apparatus 700 for determining redundant dependencies of software packages further includes a recording module for recording redundant dependencies.

[0113] The logging module is used to generate a redundancy dependency report based on the actual file data accessed;

[0114] The redundancy dependency report is used to record all redundant dependencies of the target software package.

[0115] As one implementation method, regarding how to obtain the file data actually accessed during the runtime of the target software package, the aforementioned acquisition module 702 is further used for:

[0116] The trigger detector, based on the detection configuration, obtains the system call data of the target software package during runtime in one or more operating environments, and generates the file data actually accessed by the target software package by parsing it.

[0117] File data is obtained directly from the detector.

[0118] In summary, the embodiments of this application first determine the target software package. The target software package is the software package whose redundant dependencies need to be determined. Then, based on a detector, the actual file data accessed by the target software package during runtime is obtained from one or more runtime environments. The file data includes file paths and filenames, and the runtime environment is the operating system and hardware environment that allows the target software package to run normally. Finally, the redundant dependencies of the target software package are determined based on the actual accessed file data. In this way, by directly obtaining the files accessed by the target software package throughout its operation in various runtime environments using a detector, the truly necessary runtime dependencies can be identified without manual intervention. This also avoids errors in redundant dependency judgment caused by the software implementation language, improving the efficiency of determining redundant dependencies while ensuring accuracy.

[0119] In addition, this application also provides a server, including: a memory for storing a computer program; and a processor for implementing the steps of the method for determining software package redundancy dependencies as described above when executing the computer program.

[0120] In addition, this application also provides a readable storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of the method for determining software package redundancy dependencies as described above.

[0121] Figure 8 This is a schematic diagram of a server structure provided in an embodiment of this application, combined with... Figure 8 As shown, server 800 includes processor 810 and memory 820; wherein, memory 820 stores computer programs / instructions, and processor 810 is used to execute computer instructions, causing server 800 to perform the method for determining software package redundancy dependencies described above.

[0122] In some embodiments, the processor 810 may be a central processing unit, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0123] In some embodiments, the memory 820 can be volatile memory or non-volatile memory, such as registers. Specifically, volatile memory refers to memory whose stored data is lost when the power supply is interrupted. Volatile memory primarily refers to random access memory (RAM), including static random access memory (SRAM) and dynamic random access memory (DRAM). Non-volatile memory refers to memory whose stored data is not lost even when the power supply is interrupted. Common non-volatile memories include read-only memory (ROM), optical discs, hard disks, solid-state drives (SSDs), and various memory cards based on flash memory technology.

[0124] In some embodiments, the memory 820 has executable code that the memory 820 executes to implement a method for determining software package redundancy dependencies.

[0125] The communication interface 830 is used to communicate with the outside world. For example, the communication interface 830 can serve as an external interface to receive requests to create virtual machines. It can also receive various parameters required for creating virtual machines through the communication interface 830.

[0126] A bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (ESA) bus, etc. Buses can be categorized into address buses, data buses, control buses, etc. For ease of understanding, Figure 8 It is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0127] It should be understood that the above-described server is merely illustrative. In actual use, the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. When the above-described server is a server cluster or distributed system composed of multiple physical servers, the multiple physical servers can form a blockchain, with each physical server being a node on the blockchain. The physical type of the service area can be a rack server, high-density server, GPU server, tower server, or even a blade server, rack server, etc., which are not specifically limited in this application.

[0128] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0129] The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0130] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for determining redundant dependencies in software packages, characterized in that, The methods include: Identify the target software package; The target software package is a software package whose redundant dependencies are to be determined, and the target software package is a software package that exists in multiple runtime environments; Based on the detector, file data actually accessed by the target software package during runtime is obtained from multiple operating environments; the file data includes file paths and file names; the operating environment is the software and hardware environment that meets the requirements for the normal operation of the target software package; the detector is deployed in multiple operating environments. The redundant dependencies of the target software package are determined based on the file data actually accessed; wherein, the file data actually accessed is the actual dependency of the target software package; the redundant dependencies of the target software package are: the dependencies remaining after removing the actual dependencies from all dependencies of the target software package; The method of obtaining file data actually accessed by the target software package at runtime from multiple operating environments based on the detector includes: Based on the detector, system call data of the target software package during runtime is obtained under various operating environments, and the file data actually accessed by the target software package is obtained based on the system call data.

2. The method for determining software package redundancy dependencies according to claim 1, characterized in that, Before obtaining the actual file data accessed by the target software package at runtime from multiple runtime environments based on the detector, the method also includes: Send a detection configuration to the detector; the detection configuration is used to indicate that the target software package should be the target of the detector.

3. The method for determining software package redundancy dependencies according to claim 2, characterized in that, Obtain the file data actually accessed by the target software package at runtime from multiple runtime environments, including: The trigger detector obtains system call data of the target software package during runtime under various operating environments based on the detection configuration. Obtain system call data from the detector; Generate the file data actually accessed by the target software package based on system call data.

4. The method for determining software package redundancy dependencies according to claim 2, characterized in that, Obtain the file data actually accessed by the target software package at runtime from multiple runtime environments, including: The trigger detector, based on the detection configuration, obtains system call data of the target software package during runtime under various operating environments, and parses and generates file data actually accessed by the target software package; Obtain the actual file data accessed from the detector.

5. The method for determining software package redundancy dependencies according to claim 3 or 4, characterized in that, The trigger detector, based on the detection configuration, obtains system call data of the target software package during runtime under various operating environments, including: The system calls of the target software package during runtime are obtained using system monitoring tools, and the corresponding system call data is obtained.

6. The method for determining software package redundancy dependencies according to claim 5, characterized in that, System monitoring tools include: eBPF monitoring tool and / or kprobe monitoring tool.

7. The method for determining software package redundancy dependencies according to claim 5, characterized in that, System calls include the open system call and the execve system call.

8. The method for determining software package redundancy dependencies according to claim 6, characterized in that, System calls include the open system call and the execve system call.

9. The method for determining software package redundancy dependencies according to any one of claims 1-4 or 6-8, characterized in that, Redundant dependencies of the target software package are determined based on the actual file data accessed, including: Summarize the actual file access data obtained from various operating environments; The actual accessed file data is compared with the description file corresponding to the target software package to determine the redundant dependencies of the target software package; The documentation is used to record all the dependencies of the target software package.

10. The method for determining software package redundancy dependencies according to claim 5, characterized in that, Redundant dependencies of the target software package are determined based on the actual file data accessed, including: Summarize the actual file access data obtained from various operating environments; The actual accessed file data is compared with the description file corresponding to the target software package to determine the redundant dependencies of the target software package; The documentation is used to record all the dependencies of the target software package.

11. The method for determining software package redundancy dependencies according to any one of claims 1-4 or 6-8, 10, characterized in that, The method also includes: Generate a redundancy dependency report based on the actual file data accessed; The redundancy dependency report is used to record all redundant dependencies of the target software package.

12. The method for determining software package redundancy dependencies according to claim 5, characterized in that, The method also includes: Generate a redundancy dependency report based on the actual file data accessed; The redundancy dependency report is used to record all redundant dependencies of the target software package.

13. The method for determining software package redundancy dependencies according to claim 9, characterized in that, The method also includes: Generate a redundancy dependency report based on the actual file data accessed; The redundancy dependency report is used to record all redundant dependencies of the target software package.

14. A server, characterized in that, include: Memory and processor; Memory and processor are coupled; Memory, used to store computer programs; A processor for executing a computer program to implement the steps of the method for determining software package redundancy dependencies as described in any one of claims 1 to 13.

Images