Operating system dependency structure cross-version evolution detection method and device

Abstract

The invention discloses an operating system dependency structure cross-version evolution detection method and device, and belongs to the technical field of Web operating systems. According to the method, after metadata of a multi-version software package is preprocessed, a cross-version isomorphic dependency graph is constructed, and node source and target embedding vectors are obtained through an HOPE algorithm; and in combination with source vector function semantic similarity and neighborhood Jaccard similarity, an intermediate layer candidate packet is screened, and then evolution types such as a reconstruction type and a migration type are judged through a target vector, so that accurate detection of dependent structure cross-version evolution is realized.

Description

Technical Field

[0001] This application relates to the field of Web operating system technology, and in particular to a method and apparatus for detecting cross-version evolution of operating system dependency structures. Background Technology

[0002] With the widespread adoption of web operating systems, user demand for local map applications is growing. This demands not only a smooth browsing and interactive experience but also support for offline use scenarios (such as navigation and location lookup in offline environments) to adapt to mobile and embedded devices. However, current web applications using third-party map rendering libraries face significant technical bottlenecks. Due to the differences between the web environment and the native C / C++ language runtime environment, the commonly used technical approaches have insurmountable flaws and cannot simultaneously meet the four core requirements of performance, user experience, compatibility, and security.

[0003] There are four main implementation paths in the existing technology. The first is to compile the C / C++ map library into a WebAssembly (WASM) module and interact with WASM through JavaScript. However, this method is difficult to debug, has a large package size, requires manual memory management, and has poor browser compatibility. The second is to wrap the C / C++ map library as an HTTP service in Node / C++ on the backend and have the frontend call it remotely. This solution depends on the network, is prone to lag, cannot be offline, and has high backend concurrency pressure. The third is to integrate the C / C++ map library into the App shell and communicate with the Web through JSBridge. However, this method requires maintaining two sets of communication protocols, which has high development and maintenance costs, asynchronous lifecycles, and is prone to memory leaks or crashes. The fourth is to place the native map and H5 page on different WebViews and display them on top of each other, synchronizing their states through a message bus. However, multiple WebViews on top of each other will form information silos, have limited hierarchy, and not share memory. They are prone to frame drops on low-end devices, and complex interactions are difficult to implement.

[0004] In summary, existing web map application technologies suffer from a triangular contradiction between performance, user experience, and compatibility. Prioritizing performance at the expense of compatibility, or prioritizing development experience and compatibility, fails to meet the demands for offline operation and smooth interaction. There is currently no ideal solution that is lightweight, low-latency, cross-platform, and can securely call third-party C / C++ map libraries. New methods are urgently needed to overcome the barriers between web applications and native C / C++ map libraries, simultaneously achieving offline operation, secure isolation, high-performance rendering, and adaptation to the evolving needs of web operating systems. Summary of the Invention

[0005] This application provides a method and apparatus for detecting cross-version evolution of operating system dependency structures. The technical solution is as follows: On the one hand, a method for detecting cross-version evolution of operating system dependency structures is provided, the method comprising: S1 preprocesses the metadata of multi-version operating system software packages, extracting core dependency information and version constraints; S2, Based on the preprocessed package metadata, construct a cross-version isomorphic dependency graph, where nodes in the cross-version isomorphic dependency graph represent package entities in each version, and edges represent dependencies between packages; S3, The HOPE algorithm is used to embed the nodes in the cross-version isomorphic dependency graph to obtain the source embedding vector and target embedding vector of each node. S4. Calculate the functional semantic similarity between nodes based on the source embedding vector, and combine it with the Jaccard similarity of the node neighborhood structure to filter and obtain intermediate layer candidate packages. S5. Calculate the dependency role similarity between the intermediate layer candidate package and the associated package based on the target embedding vector, and determine the evolution type of the intermediate layer candidate package according to the dependency role similarity. The evolution type includes reconstructive intermediate layer and migration intermediate layer.

[0006] Optionally, the core dependency information includes the Depends field and the Pre-Depends field, and the version constraints include operators of type >=, <, and >>; the preprocessing also includes: filtering the packages in the package metadata, retaining officially released stable packages, and excluding build tools and temporary artifacts.

[0007] Optionally, the node's attributes include pkgname, name, version, ubuntu_version, architecture, installed_size, and repo_type, wherein the name is a combination of the package's base name and version information, serving as a unique identifier for the node; The ubuntu_version attribute implicitly contains a timestamp, which is used to achieve time alignment and evolution comparison of different version nodes in the cross-version isomorphic dependency graph; The architecture attribute includes the amd64 architecture, and the repo_type attribute includes the main and universe types; The rules for constructing the edges include: For any source node, enumerate all target nodes that satisfy the version constraints and establish a directed edge between the source node and the target node.

[0008] Optionally, the key parameters of the HOPE algorithm include the decay factor β and the embedding dimension d; The attenuation factor β is 0.002, and the embedding dimension d is 512. The HOPE algorithm constructs a similarity matrix S based on Katz similarity, and obtains the source embedding matrix and the target embedding matrix by eigenvalue decomposition of the similarity matrix S.

[0009] Optionally, the source embedding vector is used to characterize the functional output influence of the corresponding node on the downstream dependent path, and the target embedding vector is used to characterize the functional input integration features of the corresponding node on the upstream dependent structure.

[0010] Optionally, the calculation method for the functional semantic similarity includes: For all software packages p that coexist in two consecutive versions Ut and Ut+1, calculate the cosine similarity between the source embedding vectors of node pt in version Ut and node pt+1 in version Ut+1, where the calculation formula is sim source (p t ,p t+1 )=cos( s (p t ), s (p t+1 )),in s( ) represents the source embedding vector of a packet, reflecting the propagation semantics of the packet to downstream packets; If the sim source (p t ,p t+1 If the value is greater than the threshold of 0.9, it indicates that the software package p remains stable in terms of semantic function. The Jaccard similarity of the node neighborhood structure includes the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 of the nodes of the software package p in versions Ut and Ut+1. Here, the 1-hop neighborhood is the set of nodes that a node directly depends on or is depended upon, and the corresponding neighborhood set is N. (1) (p t (Refers to version U) t The 1-hop neighborhood of package p in the middle, and N (1) (p t+1 (Refers to version U) t+1 (1-hop neighborhood of package p in the middle). The 2-hop neighborhood is the set of nodes that a node indirectly depends on or is depended on through one intermediate node, and the corresponding neighborhood set is N. (2) (p t (Refers to version U) tThe 2-hop neighborhood of package p in the middle, and N (2) (p t+1 (Refers to version U) t+1 (2-hop neighborhood of package p in the middle). The formulas for calculating the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 are as follows: Where, when k=1, the calculation result is J1; when k=2, the calculation result is J2.

[0011] Optionally, the criteria for filtering the intermediate layer candidate packages include: The functional semantic similarity is greater than the first threshold, and both J1 and J2 are equal to 0; The first threshold value is 0.9.

[0012] Optionally, the reconfigurable intermediate layer includes decoupled reconfiguration and convergent reconfiguration; The decoupled refactoring extracts the core functionality of the original software package into a newly added Core package, which is used to degenerate the original software package into a Shell package implementation that retains the interface; The convergent reconstruction reduces dependency paths by removing redundant intermediate layer packages, allowing the original software package to directly depend on downstream packages.

[0013] Optionally, the conditions for determining the migration-type intermediate layer include: The cosine similarity of the target embedding vectors of the Legacy package and the Core package corresponding to the intermediate layer candidate package is greater than the second threshold, and the installed_size of the intermediate layer candidate package is significantly reduced. The second threshold is 0.75, and the intermediate layer candidate package is a proxy package that is not explicitly marked "dummy".

[0014] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the operating system dependency structure cross-version evolution detection method as described above.

[0015] In this embodiment, after preprocessing the metadata of multi-version software packages, a cross-version isomorphic dependency graph is constructed. The embedding vectors of nodes source and target are obtained by the HOPE algorithm. The intermediate layer candidate packages are screened by combining the functional semantic similarity of the source vector and the neighborhood Jaccard similarity. Then, the evolution type such as reconstruction and migration is determined by the target vector, so as to achieve accurate detection of cross-version evolution of the dependency structure. Attached Figure Description

[0016] Figure 1 A flowchart of a method for detecting cross-version evolution of operating system dependency structures is shown; Figure 2 A schematic diagram illustrating the core steps in building a unified multi-version dependency graph based on Ubuntu software repository data; Figure 3 A schematic diagram illustrating the process of constructing a dependency graph and extracting knowledge across operating system versions; Figure 4 This is a diagram illustrating the distribution of Section counts for different categories. Figure 5 A schematic diagram showing the distribution of Version count for different categories; Figure 6 This is a schematic diagram illustrating the relationship between threshold and precision, recall, and F1 score. Detailed Implementation

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

[0018] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0019] Example 1 like Figure 1 The diagram shows a flowchart of a method for detecting cross-version evolution of operating system dependency structures.

[0020] The embodiments of this application include the core process of the method for detecting cross-version evolution of operating system dependency structures, covering five key steps.

[0021] S1 preprocesses the metadata of multi-version operating system software packages, extracting core dependency information and version constraints.

[0022] We preprocessed the metadata of software packages from multiple operating system versions (taking six LTS versions of Ubuntu 14.04 to 24.04 as examples) to extract core dependency information such as Depends and Pre-Depends, as well as version constraints such as >=, <, and >>. At the same time, we screened software packages, retaining officially released stable packages and excluding redundant data such as build tools and temporary artifacts, so as to provide a high-quality data source for subsequent analysis.

[0023] S2, based on the preprocessed package metadata, constructs a cross-version isomorphic dependency graph. The nodes of the cross-version isomorphic dependency graph represent package entities in each version, and the edges represent the dependency relationships between packages.

[0024] Based on the preprocessed data, a cross-version isomorphic dependency graph is constructed. Nodes represent the entities of each version of the software package (node ​​attributes include pkgname, name, version, ubuntu_version, architecture, installed_size, and repo_type, where name is a combination of the base name of the software package and version information, serving as a unique identifier for the node). Directed edges represent the dependency relationships between software packages that satisfy version constraints, thus achieving unified modeling of multi-version dependency structures.

[0025] Table 1 As shown in Table 1, these node attributes not only serve as input feature completion for graph embedding and structural comparison, but also as important supporting dimensions for subsequent package lifecycle modeling, version migration behavior prediction, and structural evolution visualization analysis.

[0026] like Figure 2As shown in the diagram, this diagram illustrates the core steps in building a unified multi-version dependency graph based on Ubuntu software repository data. The "KnowledgeExtractionSystem" on the left represents the software repository data preprocessing function, extracting basic package information (such as package name and version), dependency information (Depends field), and version constraints (such as >=, <<, etc.) from "Ubuntumanifestfiles" and "UbuntuPackagesfiles," providing foundational data for subsequent graph construction. The "Constraint-AwareEdgeFiltering" module in the middle corresponds to the dependency edge construction rules. For each dependency declaration (such as "cloud-init,Depends,python" in the example), it only enumerates target package nodes vt that satisfy the version constraints (<<2.8 and >=2.7.1-0ubuntu2), establishing a valid directed edge e=(vs,vt) to ensure the semantic accuracy of the dependency relationships. The “UnifiedMulti-VersionDependencyGraph” on the right is the final isomorphic dependency graph. Nodes (such as A, B, and C) carry implicit timestamps (u, corresponding to the “ubuntu_version” field in the node attributes, which implicitly contains system version and time information). Edges E represent dependencies between packages. The overall structure not only preserves the structural differences between packages of different Ubuntu versions, but also supports cross-version dependency structure alignment and evolution analysis through unified node attributes and edge constraint rules, providing a basic carrier for subsequent evolution detection based on graph embedding (such as intermediate layer phenomenon identification).

[0027] like Figure 3 As shown, Figure 3This is a flowchart illustrating the process of constructing a dependency graph and extracting knowledge across operating system versions. The "KnowledgeExtractionSystem" module on the left extracts data from the Ubuntumanifest and UbuntuPackages files, generating a node set V (node ​​v is represented as (p, vp, w)) containing attributes such as package names, version parameters, and weights, where p is the package entity, vp is the version constraint parameter, and w is the dependency weight. Based on dependency declarations and version constraints (such as "cloud-initDependspython<<2.8" and "cloud-initDependspython>=2.7.1-0ubuntu2" in the example), it generates a set of edges E representing dependencies (edge ​​e is represented as ((vs, vt)), where (vs) is the source node and (vt) is the target node). The "UnifiedMulti-VersionDependencyGraph" on the right is a cross-version isomorphic dependency graph obtained after "Constraint-AwareEdgeFiltering". Nodes represent multi-version package entities, and edges represent dependencies that satisfy version constraints, realizing unified modeling of multi-version dependency structures and providing a foundation for subsequent graph embedding and evolution detection.

[0028] Figure 3 In this paper, we formally model the dependency paths of Ubuntu multi-version packages as a directed graph G=(V,E).

[0029] V is a set of nodes, and each node v i =(p i ,v i p ,u i ) indicates the operating system version u i Chinese name p i And the version is v i p The software package; E is the set of directed edges, where each edge e = (v s ,v t ) represents the source node v s The corresponding software package depends on the target node v t The other package it represents; implicitly, it contains a set of timestamps T, representing the system version u to which the node belongs. i This is to support cross-version embedding alignment and evolution comparison.

[0030] For each dependency declaration `psDependsθpt`, where θ is a version constraint (e.g., >= 1.2, < 2.0), we enumerate all target package nodes `vt=(pt, vpt, ut)` in the graph that satisfy this constraint, and `vpt` satisfies the version constraint. Given θ, establish the edge (vs, vt) ∈ E. For example, if node A1=(A, 1.0, 18.04) declares a dependency on package B with version 2 or higher, and the repository contains B2=(B, 2, 18.04), B3=(B, 3, 20.04), and B4=(B, 4, 22.04), then the following dependency edge set will be established, E. {(A1,B2),(A1,B3),(A1,B4)}.

[0031] To ensure semantic consistency and structural comparability of isomorphic graphs in cross-version evolution analysis, we normalized and enhanced the graph structure, mainly in the following two aspects.

[0032] First, dependency information is simplified and focused. When constructing the dependency graph, we only retain the core dependency information fields Depends and Pre-Depends, ignoring non-mandatory relationships such as Recommends, Suggests, and Enhancements to reduce structural redundancy and semantic interference. At the same time, we only retain officially released stable software packages from the repository packages, excluding build tools and temporary artifacts to improve the stability and interpretability of the graph structure.

[0033] Secondly, the upstream and downstream structure of leaf nodes is enhanced. To avoid some terminal nodes with an in-degree or out-degree of 0 affecting the embedding quality due to a lack of context, we perform first-order adjacency completion on all leaf nodes during the graph construction phase to enhance their upstream and downstream structural information, thereby improving the trainability and discriminative ability of graph embedding.

[0034] Furthermore, we align node identifiers for software packages with the same name across different versions using a unified naming convention, laying the foundation for subsequent cross-version similarity measurement and structural evolution analysis. All nodes retain their respective system version information, ensuring that the time dimension in the graph is traceable and interpretable.

[0035] Through the above normalization and enhancement strategies, the final constructed isomorphic dependency graph is not only structurally compact and consistent, but also retains key dependency change information in multiple version evolutions, supporting the efficient execution of subsequent similarity analysis based on node embedding and intermediate layer phenomenon identification and classification.

[0036] Specifically, for a graph G=(V,E), node v i The Hope embedding is defined as: Where S is the Katz similarity matrix of the graph, defined as: , A is the adjacency matrix of graph G; β is the attenuation factor, which controls the degree of influence of higher-order paths; I is the identity matrix, with 1s on the diagonal and 0s on the rest. Its dimensions are the same as those of the adjacency matrix A.

[0037] After performing eigenvalue decomposition on the similarity matrix S, two embedding matrices U are obtained. s U t ∈R ∣V∣×d， Let be the source embedding and the target embedding, respectively, and d be the embedding dimension. For any node v i ∈V, its embedding vector is represented as (v i )∈R d : In this context, the Source embedding represents the impact characteristics of a software package on its downstream dependency paths, reflecting its "functional output"; the Target embedding represents the integration characteristics of a software package on its upstream dependency structure, reflecting its "functional input" or dependency role.

[0038] Based on the above embedding, let's assume two operating system versions u i, u j The nodes in the data are v i =(p i ,vs pi ,u i ) ， v j =(p j ,vs pj ,u j ), whose embedding vector is (v i )∈R d , (v j )∈R d Then the similarity between any two nodes is defined as sim(vi,vj)=cos( (vi), (vj))=( (vi) (vj)) / ∥ (vi)∥ ∥ (vj)∥.

[0039] Furthermore, for a certain key software package p, its version set U={u1,u2,…,u…} is defined. n The set of embedded vectors in} is Φ p ={ (v i )∣v i =(p,v pi ,u i ),ui ∈U}. We can construct its version evolution similarity matrix: .

[0040] Each element in the matrix measures the similarity of the functional performance of software package p between two versions. By analyzing the changing trends of this similarity matrix, the functional migration trajectory of software package p during its long-term evolution can be depicted, providing support for the automatic identification and evolutionary analysis of intermediate layer phenomena.

[0041] S3 uses the HOPE algorithm to embed nodes in the cross-version isomorphic dependency graph, obtaining the source embedding vector and target embedding vector for each node.

[0042] The HOPE algorithm is used to embed nodes in cross-version isomorphic dependency graphs. The key parameters of the HOPE algorithm are the decay factor β of 0.002 and the embedding dimension d of 512. The algorithm constructs a similarity matrix S based on Katz similarity and obtains the source embedding matrix and the target embedding matrix through feature decomposition of S. The source embedding vector represents the influence of the node on the functional output of the downstream dependency path, and the target embedding vector represents the functional input integration feature of the node on the upstream dependency structure.

[0043] S4 calculates the functional semantic similarity between nodes based on the source embedding vector, and combines it with the Jaccard similarity of the node neighborhood structure to select intermediate layer candidate packages.

[0044] Based on the source embedding vector, the functional semantic similarity of coexisting packages in consecutive versions is calculated; combined with the Jaccard similarity of the node neighborhood structure, intermediate layer candidate packages with "functional semantic similarity > 0.9 and J1=J2=0" are selected.

[0045] S5 calculates the dependency role similarity between intermediate layer candidate packages and associated packages based on the target embedding vector, and determines the evolution type of intermediate layer candidate packages based on the dependency role similarity. The evolution type includes reconstructed intermediate layers and migration intermediate layers.

[0046] Based on the target embedding vector, the dependency role similarity between intermediate layer candidate packages and related packages (such as Legacy packages and Core packages) is calculated, and the evolution type of intermediate layer candidate packages (including reconstructed intermediate layers and migration intermediate layers) is determined accordingly.

[0047] For candidate packets, this paper further introduces target embedding similarity as the core criterion for distinguishing different intermediate layer evolution modes. Unlike source embedding, which focuses on the downstream propagation influence of nodes, target embedding mainly reflects the semantic role of nodes in receiving upstream dependencies. By comparing the target embedding vectors of packets in different versions, we can determine whether their dependency "receiving mode" has undergone fundamental changes, thereby helping to determine whether their evolution mode is reconstruction-type or migration-type. We make the determination based on the following rules: FunctionClassifyIntermediateLayer(Legacy,Shell,Core): sim_aa=Cosine(TargetEmbedding(Legacy),TargetEmbedding(Shell)) sim_ap=Cosine(TargetEmbedding(Legacy),TargetEmbedding(Core)) ifsim_aa≥τ_high andsim_ap<τ_low: return "Refactoring" elifsim_ap≥τ_high: return "Transition" else: return "Uncertain" Where τ_high and τ_low are empirically set high and low similarity thresholds (e.g., 0.9 and 0.3), respectively. The two core similarity metrics in this pseudocode represent the following situations: sim aa =cos( t (a prev ), t (a curr ): Measures the similarity between the original package and the front-end shell package in terms of "dependency roles"; ap =cos( t (a prev ), t (p curr ): Measures the degree of inheritance between the original package and the intermediate logical package in terms of dependency structure.

[0048] If sim aa Gao Er sim apA low value indicates that the interface role of the original package is mainly retained by a′, while the newly added intermediate layer package p is in a different position in the dependency graph. Although the functional logic has been migrated, the dependency semantics have not been continued, reflecting a typical refactoring type; conversely, if sim ap The high similarity level indicates that the structural role of the original package 'a' is directly inherited by 'p', and 'a' itself usually becomes a transitional shell package without logical function. At this point, the evolution conforms to the characteristics of migration. Through the above embedding+structure combined pattern recognition strategy, we can effectively classify intermediate layer phenomena in the evolution of operating system software packages, providing a foundation for subsequent compatibility analysis and lifecycle prediction.

[0049] In summary, by integrating multi-version dependency information and embedding it into a graph, this approach overcomes the limitations of traditional static dependency analysis, which can only capture local changes, and achieves system-level modeling of the global dependency structure evolution across versions. The HOPE algorithm preserves the directionality and long-range dependency characteristics of the dependency graph, and captures dependency transitivity more accurately than methods such as GCN, thus improving the accuracy of evolution feature extraction. The dual-dimensional screening of "functional semantic similarity + structural similarity" accurately identifies the intermediate layer phenomenon of "functional stability but structural reconstruction," providing an effective means for identifying operating system compatibility risks and analyzing structural evolution patterns.

[0050] Example 2 Furthermore, core dependency information, including the Depends and Pre-Depends fields, and version constraints including operators of type >=, <, and >>; preprocessing also includes: filtering packages in the package metadata, retaining officially released stable packages, and excluding build tools and temporary artifacts.

[0051] By clearly defining the scope of core dependency information and software package selection rules, we can reduce the interference of redundant and invalid data on subsequent analysis, ensure that the preprocessed data truly reflects the core dependency structure of the operating system, provide a reliable data source for the accurate construction of cross-version dependency graphs, and indirectly improve the accuracy of subsequent evolution detection.

[0052] Example 3 Furthermore, the node's attributes include pkgname, name, version, ubuntu_version, architecture, installed_size, and repo_type. Among these, name is a combination of the package's base name and version information, serving as a unique identifier for the node.

[0053] The ubuntu_version attribute implicitly contains timestamps, which are used to achieve time alignment and evolution comparison of different version nodes in the cross-version isomorphic dependency graph; the architecture attribute includes the amd64 architecture, and the repo_type attribute includes the main and universe types.

[0054] The rules for constructing edges include: for any source node, the dependency declaration of the corresponding package, enumerating all target nodes that satisfy the version constraints, and establishing directed edges between the source node and the target node.

[0055] Further node attributes provide a foundation for time-dimensional alignment of cross-version dependency structures and multi-dimensional feature analysis (such as evolutionary differences under different architectures and repository types); directed edge construction rules ensure the accuracy and consistency of dependency relationships, enabling cross-version isomorphic dependency graphs to accurately depict the dependency transit logic between software packages, providing precise topological structure support for subsequent graph embedding and evolution detection.

[0056] Example 4 Furthermore, the key parameters of the HOPE algorithm include the decay factor β and the embedding dimension d.

[0057] The attenuation factor β is 0.002, the embedding dimension d is 512, the HOPE algorithm constructs a similarity matrix S based on Katz similarity, and obtains the source embedding matrix and the target embedding matrix by decomposing the similarity matrix S.

[0058] The specific values ​​of β and d in the embodiments of this application are parameter combinations that have been experimentally verified to achieve the optimal balance between "preserving the semantic features of dependencies" and "computational efficiency". Based on the matrix construction and feature decomposition of Katz similarity, the directed long-range dependency information of the dependency graph is effectively preserved. Compared with traditional GCN, it can more accurately capture the transitive characteristics of dependency relationships, making the source and target embedding vectors more accurately reflect the "functional output" and "input integration" features of the nodes, and providing high-quality vector representations for subsequent similarity calculation and evolution type determination.

[0059] Example 5 Furthermore, the source embedding vector is used to characterize the functional output impact of the corresponding node on the downstream dependent path, and the target embedding vector is used to characterize the functional input integration features of the corresponding node on the upstream dependent structure.

[0060] By clarifying the "semantic division of labor" between the two types of embedded vectors, the subsequent calculation of "functional semantic similarity" (based on source vector) and "dependency role similarity" (based on target vector) has a clear semantic logic, ensuring that the node evolution characteristics are quantified from the two dimensions of "functional output" and "input integration", thereby improving the accuracy and interpretability of evolution type determination.

[0061] Example 6 Furthermore, the calculation method for functional semantic similarity includes the following:

[0062] S11, for all packages p that coexist in two consecutive versions Ut and Ut+1, calculate the cosine similarity between the source embedding vectors of node pt in version Ut and node pt+1 in version Ut+1 of package p, where the calculation formula is sim source (p t ,p t+1 )=cos( s (p t ), s (p t+1 )),in s( ) represents the source embedding vector of a packet, reflecting the propagation semantics of the packet to downstream packets.

[0063] S12, if sim source (p t ,p t+1 If the value is greater than the threshold of 0.9, it indicates that the software package p remains stable in terms of semantic function.

[0064] The Jaccard similarity of the node neighborhood structure includes the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 of the nodes of the package p in versions Ut and Ut+1.

[0065] Here, the 1-hop neighborhood is the set of nodes that a node directly depends on or is depended upon, and the corresponding neighborhood set is N. (1) (p t (Refers to version U) t The 1-hop neighborhood of package p in the middle, and N (1) (p t+1 (Refers to version U) t+1 (1-hop neighborhood of package p).

[0066] Here, a 2-hop neighborhood is the set of nodes that a node indirectly depends on or is depended on through one intermediate node, and the corresponding neighborhood set is N. (2) (p t(Refers to version U) t The 2-hop neighborhood of package p in the middle, and N (2) (p t+1 (Refers to version U) t+1 (2-hop neighborhood of package p in the middle).

[0067] The formulas for calculating the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 are as follows: Where, when k=1, the calculation result is J1; when k=2, the calculation result is J2.

[0068] As can be seen, cosine similarity calculation accurately quantifies the stability of node functional semantics, providing a quantitative basis for screening "functionally stable" intermediate layer candidate packages; the Jaccard similarity formula is used to effectively capture the degree of change in the local dependency structure of nodes, and combined with functional semantic similarity, it achieves accurate quantification of the core feature of the intermediate layer, "functionally stable but structurally changing", providing a reliable two-dimensional judgment standard for subsequent candidate package screening.

[0069] Example 7 Furthermore, the criteria for selecting intermediate layer candidate packages include the following.

[0070] Functional semantic similarity is greater than a first threshold, and both J1 and J2 are equal to 0; the first threshold is 0.9. By combining the screening conditions of "functional stability (high semantic similarity)" and "significant structural change (J1 and J2 are 0)," intermediate layer candidate packets that are "functionally stable but dependent on structural reconstruction" are accurately identified. This solves the problems of low accuracy and reliance on empirical thresholds in existing technologies for intermediate layer identification, enabling clear and quantifiable standards for intermediate layer candidate packet identification and improving the objectivity and accuracy of evolution detection.

[0071] Example 8 Furthermore, the reconfigurable intermediate layer includes decoupled reconfiguration and convergent reconfiguration.

[0072] Decoupling refactoring extracts the core functionality of the original software package into a new Core package, which degenerates the original software package into a Shell package implementation that retains the interface; convergent refactoring removes redundant intermediate layer packages, which compresses the dependency path so that the original software package directly depends on downstream packages.

[0073] Based on different evolutionary mechanisms, intermediate layer phenomena can be divided into two categories: reconstructive and migratory. Reconstructive phenomena can be further subdivided into decoupled reconstruction and convergent reconstruction. The table below summarizes the typical role definitions under different evolutionary modes.

[0074] In the decoupled refactoring, the core functionality of the Legacy package `a` is extracted into the newly introduced Core package `p`, while the original package is "slimmed down" into a Shell package `a'` that retains only the necessary interfaces. This structural refactoring can be formally represented as a (Legacy) → c (Downstream). The pattern a′ (Shell) → p (Core) → c (Downstream) typically originates from logical decoupling and functional splitting: the Shell package continues to provide command-line entry points or metadata declarations, while the Core package is responsible for carrying the split business logic. This preserves the availability of the original functionality while improving module reusability and the flexibility of minimal system deployment. In contrast, convergent refactoring involves removing redundant nodes and compressing the path. The Core package p, which was originally in the path, is no longer maintained as an independent entity; its functionality is directly integrated into the Downstream package c'. The original Legacy package a then resumes its direct dependency on the Downstream package c. The corresponding evolution path can be described as a (Legacy) → p (Core) → c (Downstream package). The evolution from a (Legacy) package to c (Downstream) does not create a new shell package. Instead, it simplifies the dependency structure by removing redundant intermediate layers. This stripping typically occurs after the underlying library (such as glibc) has absorbed compatibility or multi-architecture support features. Redundant dependencies are eliminated through path cleanup and maintenance simplification, resulting in a flatter system dependency graph and higher resolution efficiency. In migration-type evolution, the Legacy package 'a' is completely replaced by a functionally equivalent new package, the Core package 'p', while the original package degenerates into a dummy shell package to carry historical dependencies. The actual functionality is handled by the Core package 'p'. This refactoring process can be described as a (Legacy) → c (Downstream package). a′ (Shell, dummy) → p (Core) → c (Downstream package). This pattern is used in contexts such as package renaming, ABI upgrades, or cross-system compatibility migration. For example, the new package p provides equivalent or even better functionality, while the old package a is retained as a compatibility bridge to prevent downstream components that still rely on the old package name from failing.

[0075] This application further refines the specific types and implementation logic of reconfigurable intermediate layers, clarifies the technical characteristics of two typical reconfiguration modes, namely "decoupling" and "convergence," and provides a more detailed classification basis for the analysis of the evolution law of operating system dependency structure. This helps to specifically evaluate the impact of different reconfiguration modes on operating system compatibility and dependency complexity.

[0076] Example 9 Furthermore, the conditions for determining a migratory intermediate layer include the following:

[0077] The Legacy package corresponding to the intermediate layer candidate package has a cosine similarity of the target embedding vector to the Core package that is greater than the second threshold, and the installed_size of the intermediate layer candidate package is significantly reduced; the value of the second threshold is 0.75, and the intermediate layer candidate package is a proxy package that is not explicitly marked "dummy".

[0078] By jointly determining the similarity of target embedding vectors (reflecting the consistency of dependency roles) and installation size (reflecting the degree of functional lightweighting), combined with the feature of "unannotated dummy", implicit migrating proxy packages can be effectively identified. This solves the problem of difficulty in detecting unannotated migrating intermediate layers in existing technologies, improves the completeness and accuracy of migrating intermediate layer identification, and provides key technical means for the analysis of operating system dependency migration behavior.

[0079] Example 10 This application also includes an experimental analysis section.

[0080] In this study, we selected the Long Term Support (LTS) versions of Ubuntu as the main objects of analysis, covering six versions from Ubuntu 14.04 to 24.04. Ubuntu LTS versions are released every two years and promise five years of official support, including security updates and maintenance patches

[18] . This release and support strategy ensures compatibility between versions and reduces drastic changes to the core components of the system, making it an ideal basis for analyzing the evolution trend of operating system software packages.

[0081] We obtained the package metadata for each version from the official Ubuntu mirror site

[19] and constructed a cross-version isomorphic dependency graph to analyze the structural evolution relationship between key packages. At the same time, we supplemented the new nodes and new dependency paths introduced in the non-LTS version, especially the neighborhood information of the non-LTS nodes, to avoid the problem of lack of upstream and downstream path integrity in the embedding vector. In addition, we also expanded the neighborhood of the leaf nodes to ensure that the key package nodes have higher quality embedding vectors.

[0082] Identification and analysis of intermediate layer phenomena.

[0083] To visually illustrate all the intermediate layer phenomenon packages and their evolution types identified in this study, we have compiled a table. The table lists the name of each legacy package exhibiting an intermediate layer phenomenon, the corresponding operating system version in which it evolved, the core package acting as the intermediate layer, and the corresponding evolutionary classification (Refactoring or Transition). It is worth noting that among the identified samples, there is a special case of Decoupled: the cosine similarity of the target embedding vectors between the legacy package `eatmydata` and its corresponding intermediate core package `libeatmydata1` is higher than a set threshold. This phenomenon is due to the relatively closed local dependency subgraph structure formed by this pair of packages. The upstream dependencies of `libeatmydata1` are almost entirely composed of `eatmydata` alone, resulting in a high degree of structural overlap in their upstream dependency distributions. After SVD dimensionality reduction, this structural similarity causes them to point in similar directions in the embedding space, thus leading to a higher cosine similarity.

[0084] This phenomenon suggests that when determining structural similarity based on graph embedding vectors, for some package pairs that have a high degree of coupling but have actually undergone module decoupling, it is necessary to combine the dependency graph structure features for additional semantic supplementary analysis to avoid misjudgment.

[0085] Overall statistical characteristics analysis of intermediate layer candidates.

[0086] To quantify the prevalence of intermediate layer evolution in the Ubuntu LTS series, we statistically analyzed the number of identified intermediate layer candidate packages and their respective sections (functional categories) in each version. First, after aggregating by section, we obtained the following... Figure 4 The distribution shown is illustrated in the line chart, which displays the "Sectioncount" for different categories (such as libs, text, x11, etc.).

[0087] The horizontal axis represents the category, and the vertical axis represents the section count. The blue line shows that the libs class has the highest section count (about 8), followed by text, x11, and kernel, whose section counts gradually decrease. utils and the following misc, java, and editors remain around 2, while gnome, net, and devel drop to 1 and remain stable. Overall, the section count gradually decreases with the change of category.

[0088] As can be seen, among the candidate packages for intermediate layer phenomena, low-level libraries (libs) account for the highest proportion, followed by text processing (text) and graphics protocol (x11) related packages. This is highly consistent with the actual situation that the core components of the operating system and user interface tools have been continuously reconstructed in the long-term evolution.

[0089] Further statistics were compiled on the number of intermediate layer candidate packages in each LTS version (16.04 "Xenial", 18.04 "Bionic", 20.04 "Focal", 22.04 "Jammy", 24.04 "Noble"). The results are as follows: Figure 5 As shown, the line chart presents the "Versioncount" corresponding to different version categories (such as 16xenial, 18bionic, etc.). The horizontal axis represents the version category, and the vertical axis represents the Versioncount. The blue line shows that the Versioncount was 8 in 16xenial, rose to the highest (12) in 18bionic, then decreased in 20focal, rebounded in 22jammy, and decreased again in 24noble. Overall, it showed a trend of "rise-fall-small fluctuation", reflecting the difference in the number of versions under different versions.

[0090] Looking at the version evolution trend, the number of middleware candidates peaked in version 18.04, after which the number of new candidates gradually declined. This change may reflect the frequent splitting and replacement during early large-scale architectural adjustments, while as more mature versions are released, repository maintainers tend to stabilize the middleware design.

[0091] Based on the above statistics, we have verified the prevalence and systematic nature of intermediate layer evolution in major versions of operating systems: low-level libraries and key tools are often the high-incidence points for structural refactoring, while the intensity of evolution shows a characteristic of first increasing and then stabilizing with the maturity of the system.

[0092] Verification of the accuracy of intermediate layer type classification.

[0093] To verify the effectiveness of the proposed intermediate layer classification method, we use software packages explicitly marked as "dummy" or "transitional" in software repositories as a standard truth set. These tags are typically provided by official repository maintainers and clearly indicate that a package has lost its original functionality and is only used as a compatibility interface or for migration transition, thus naturally conforming to the definition of a transitional intermediate layer. We manually verify the actual evolution type of such packages to evaluate the accuracy of classification performance.

[0094] Experimental results show that, Figure 6As shown, the classification method proposed in this study exhibits good performance in the identification of substitution-type intermediate layers, with a precision of 88.5%, a recall of 88.5%, and an overall F1 score of 88.5%. The line graph reflects the relationship between the threshold and precision, recall, and F1 score.

[0095] The horizontal axis represents Threshold (0.50-0.95), and the vertical axis represents Score. Among the blue square line (Precision), red cross line (Recall), and green dot line (F1Score), when Threshold is low (0.50-0.70), Recall is stable at around 0.90, Precision is above 0.85, and F1Score is stable. When Threshold exceeds 0.75, Recall drops significantly, Precision drops slowly, and F1Score decreases with Recall. The dashed line marks the area near the "optimal threshold of 0.75," indicating a good balance between precision and recall.

[0096] In addition, we also conducted a sensitivity analysis on the embedding vector similarity threshold, such as Figure 6 The results show that the classification accuracy is optimal when the cosine similarity threshold between the target embedding vectors of the simap (Legacy package) and the core package is set around 0.75. This result demonstrates the rationality and stability of our chosen threshold parameter, making it applicable to software repository datasets of varying sizes and complexities.

[0097] Verification of the method's generalization ability.

[0098] To further verify the generalization ability of the proposed isomorphic dependency graph-based evolutionary analysis framework, we additionally selected non-LTS (non-Long Term Support) versions of Ubuntu for supplementary experiments. We applied the exact same experimental procedures as the LTS versions to the non-LTS series of Ubuntu (such as Ubuntu 15.04, 17.04, 19.04, 21.04, and 23.04), namely, the isomorphic graph construction, embedding feature extraction, and intermediate layer phenomenon identification methods, to analyze the dependency structure evolution of these versions.

[0099] The experimental results show that the analytical framework proposed in this study not only performs well in the Ubuntu LTS environment, but also accurately identifies and classifies intermediate layer evolution phenomena in non-LTS versions, demonstrating the robustness and good generalization performance of the method. This further enhances the practical value and applicability of the proposed method.

[0100] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0101] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above descriptions are merely optional embodiments of this application and are not intended to limit the application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for detecting cross-version evolution of operating system dependency structures, characterized in that, The method includes: Preprocess the metadata of multi-version operating system software packages to extract core dependency information and version constraints; Based on the preprocessed package metadata, a cross-version isomorphic dependency graph is constructed. The nodes of the cross-version isomorphic dependency graph represent package entities in each version, and the edges represent the dependency relationships between packages. The HOPE algorithm is used to embed nodes in the cross-version isomorphic dependency graph to obtain the source embedding vector and target embedding vector of each node. Based on the source embedding vector, the functional semantic similarity between nodes is calculated, and combined with the Jaccard similarity of the node neighborhood structure, intermediate layer candidate packets are selected. The dependency role similarity between the intermediate layer candidate package and the associated package is calculated based on the target embedding vector. The evolution type of the intermediate layer candidate package is determined based on the dependency role similarity. The evolution type includes reconstructive intermediate layer and migration intermediate layer.

2. The method according to claim 1, characterized in that, The core dependency information includes the Depends field and the Pre-Depends field; the version constraints include operators of type >=, <, and >>; the preprocessing also includes: filtering the packages in the package metadata, retaining officially released stable packages, and excluding build tools and temporary artifacts.

3. The method according to claim 1, characterized in that, The node's attributes include pkgname, name, version, ubuntu_version, architecture, installed_size, and repo_type, where name is a combination of the package's base name and version information, serving as a unique identifier for the node; The ubuntu_version attribute implicitly contains a timestamp, which is used to achieve time alignment and evolution comparison of different version nodes in the cross-version isomorphic dependency graph; The architecture attribute includes the amd64 architecture, and the repo_type attribute includes the main and universe types; The rules for constructing the edges include: For any source node, enumerate all target nodes that satisfy the version constraints and establish a directed edge between the source node and the target node.

4. The method according to claim 1, characterized in that, The key parameters of the HOPE algorithm include the attenuation factor β and the embedding dimension d; The attenuation factor β is 0.002, and the embedding dimension d is 512. The HOPE algorithm constructs a similarity matrix S based on Katz similarity, and obtains the source embedding matrix and the target embedding matrix by eigenvalue decomposition of the similarity matrix S.

5. The method according to claim 1, characterized in that, The source embedding vector is used to characterize the functional output influence of the corresponding node on the downstream dependent path, and the target embedding vector is used to characterize the functional input integration feature of the corresponding node on the upstream dependent structure.

6. The method according to claim 1, characterized in that, The calculation method for the functional semantic similarity includes: For all software packages p that coexist in two consecutive versions Ut and Ut+1, calculate the cosine similarity between the source embedding vectors of node pt in version Ut and node pt+1 in version Ut+1, where the calculation formula is sim source (p t ,p t+1 )=cos( s (p t ), s (p t+1 )),in s( ) represents the source embedding vector of a packet, reflecting the propagation semantics of the packet to downstream packets; If the sim source (p t ,p t+1 If the value is greater than the threshold of 0.9, it indicates that the software package p remains stable in terms of semantic function. The Jaccard similarity of the node neighborhood structure includes the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 of the nodes of the software package p in versions Ut and Ut+1. Here, the 1-hop neighborhood is the set of nodes that a node directly depends on or is depended upon, and the corresponding neighborhood set is N. (1) (p t (Refers to version U) t The 1-hop neighborhood of package p in the middle, and N (1) (p t+1 (Refers to version U) t+1 (1-hop neighborhood of package p in the middle). The 2-hop neighborhood is the set of nodes that a node indirectly depends on or is depended on through one intermediate node, and the corresponding neighborhood set is N. (2) (p t (Refers to version U) t The 2-hop neighborhood of package p in the middle, and N (2) (p t+1 (Refers to version U) t+1 (2-hop neighborhood of package p in the middle). The formulas for calculating the 1-hop neighborhood Jaccard similarity J1 and the 2-hop neighborhood Jaccard similarity J2 are as follows: Where, when k=1, the calculation result is J1; when k=2, the calculation result is J2.

7. The method according to claim 1, characterized in that, The criteria for filtering the intermediate layer candidate packages include: The functional semantic similarity is greater than the first threshold, and both J1 and J2 are equal to 0; The first threshold value is 0.

9.

8. The method according to claim 1, characterized in that, The reconfigurable intermediate layer includes decoupled reconfiguration and convergent reconfiguration; The decoupled refactoring extracts the core functionality of the original software package into a newly added Core package, which is used to degenerate the original software package into a Shell package implementation that retains the interface; The convergent reconstruction reduces dependency paths by removing redundant intermediate layer packages, allowing the original software package to directly depend on downstream packages.

9. The method according to claim 1, characterized in that, The conditions for determining the migratory intermediate layer include: The cosine similarity of the target embedding vectors of the Legacy package and the Core package corresponding to the intermediate layer candidate package is greater than the second threshold, and the installed_size of the intermediate layer candidate package is significantly reduced. The second threshold is 0.75, and the intermediate layer candidate package is a proxy package that is not explicitly marked "dummy".

Images