Method and system for automated integration of software dependencies based on metapackaging

Abstract

The present application relates to the technical field of embedded system construction, and particularly relates to a software dependency automatic integration method and system based on meta packaging, wherein the method comprises the following steps: S1, creating a meta packaging framework in an embedded construction system, and defining a construction stage hook through a Makefile file; S2, automatically deploying pre-compiled software packages and shared dependent libraries to a target directory of the construction system through a resource injection script; S3, parsing a metadata file of the pre-compiled software packages, extracting dependency relationship information, and generating a global dependency relationship list based on a directed acyclic graph topological sorting algorithm; S4, using a dependency aggregation script to write the global dependency relationship list to a dependency declaration configuration of the meta packaging. Through implementation of the present application, the problems of dependency sequence disorder and metadata audit failure during integration of an embedded system are solved, and the reliability of system integration is improved, the system construction efficiency is optimized, the security of system construction is enhanced, and the maintainability and expansibility of system construction are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded system construction, in particular to a software dependency automatic integration method and system based on meta-package, which is suitable for firmware development scenarios of embedded Linux systems such as OpenWrt. BACKGROUND

[0002] In the firmware development process of embedded systems, especially network devices based on OpenWrt, a large number of function modules developed by different teams in the form of pre-compiled ipk packages need to be integrated. For these pre-compiled packages from different sources, the conventional integration method is to create a "meta-package" for all pre-compiled packages. This meta-package itself does not contain actual functions, and its Makefile declares that it depends on all pre-compiled packages that need to be integrated through the DEPENDS field. In theory, when this meta-package is selected in the build system, the build system should automatically install all dependent pre-compiled ipk packages into the final firmware file system.

[0003] However, this simple method has fatal flaws in practice. First, the dependency resolution fails during construction: when the build system processes the installation list, if a package's dependencies are located after it in the list, the system will report an error cannot find dependency because the meta information of the dependencies has not been loaded, causing the construction to be interrupted. This exposes the fact that simple DEPENDS declarations cannot guarantee the correct package processing order. Second, the metadata audit fails during packaging: during the packaging of individual packages, the build system performs dependency auditing to check whether all library files required by the package are provided by the packages in its DEPENDS list. If the pre-compiled package's Makefile does not explicitly declare that it depends on the library file provider, even if the library can be found during linking, the metadata audit during packaging will still fail due to missing dependencies errors. These problems result in low reliability, low efficiency, low security, and high maintenance costs in traditional embedded system integration, which seriously affects firmware development efficiency. SUMMARY

[0004] Based on the above status quo, the present application aims to address the two core problems of dependency order confusion and metadata audit failure when integrating pre-compiled software packages in embedded systems, which result in low reliability, low efficiency, low security, and high maintenance costs in system construction. The present application provides a software dependency automatic integration method and system based on meta-package, which realizes the improvement of construction success rate, the reduction of manual maintenance cost, and the enhancement of cross-scenario adaptation ability through dynamic dependency aggregation, construction process optimization, and full-link trusted verification.

[0005] The technical solution adopted by the present application to solve its technical problems is as follows:

[0006] In a first aspect, the present application provides a software dependency automatic integration method based on meta packaging, comprising the following steps: S1, creating a meta packaging framework in an embedded Linux construction system, the framework defining a construction stage hook through a Makefile file, including a resource injection script and a dependency aggregation script; S2, automatically deploying a pre-compiled software package and a shared dependency library to a target directory of the construction system through the resource injection script; S3, parsing a metadata file of the pre-compiled software package, extracting dependency relationship information, and generating a global dependency relationship list based on a directed acyclic graph topological sorting algorithm; S4, using the dependency aggregation script to write the global dependency relationship list to a dependency declaration configuration of the meta packaging.

[0007] Further, the method of creating the meta packaging framework comprises the following steps: S11, creating a directory structure of the meta packaging framework, including a Makefile file for defining construction rules and hooks, a scripts directory for storing the resource injection and dependency aggregation scripts, a config directory for storing configuration parameters, and a metadata directory for saving a pre-compiled software package metadata template; S12, defining construction stage hooks in the Makefile, including hooks for triggering resource injection and dependency aggregation, hooks for environment initialization before construction, and hooks for cleaning up temporary files and intermediate products; S13, writing an automatic resource injection script, which is used for copying the pre-compiled software package to the target directory of the construction system, injecting the shared dependency library into the system directory, and calling the script to perform the injection operation through the Makefile; S14, developing a dependency resolution script, which extracts a Depends field by parsing metadata, generates an acyclic dependency sequence using a topological sorting algorithm, and integrates a conflict detection mechanism to identify circular dependencies and generate an alarm log; S15, embedding a full-link trusted verification mechanism, including generating a material file by recording source code versions and construction parameters, signing a hash value of the pre-compiled software package using a digital signature tool, and writing key construction commands into a log file and calculating a hash check value to realize log integrity protection.

[0008] Further, the resource injection script automatically deploys the pre-compiled software package and the shared dependency library to the target directory of the construction system, and the mechanism of resource injection is realized through the following steps: S21, inserting an anchor detection function in the initialization stage of the pre-compiled software package installation script, which detects the injection state of the shared dependency library in the target directory in real time through a polling mechanism; S22, defining a dependency waiting function, which verifies the integrity and interface compatibility of the shared dependency library at runtime based on the output result of the anchor detection function; S23, setting a configurable timeout threshold, when the dependency waiting function does not detect that the dependency library is ready within the threshold time, automatically triggering the installation process to terminate and generating an error report.

[0009] Further, the global dependency list is generated based on a directed acyclic graph topological sorting algorithm, including the following steps: S31, constructing a pre-compiled software package dependency graph, wherein nodes represent pre-compiled software packages and edges represent dependency relationships between pre-compiled software packages; S32, performing topological sorting on the dependency graph to generate an initial sequence that satisfies the dependency order; S33, optimizing and adjusting the initial sequence according to a preset priority parameter; and S34, outputting the optimized dynamic aggregation global dependency list.

[0010] Further, the global dependency list is written back to the dependency declaration configuration of the metapackage using a dependency aggregation script, specifically including the following steps: S41, parsing the original dependency declaration in the metapackage configuration file to extract existing dependencies to generate a baseline dependency set; S42, comparing the global dependency list with the baseline dependency set to identify new dependencies, obsolete dependencies, and version conflicts; and S43, based on the comparison result, reconstructing the dependency declaration configuration using an incremental update strategy.

[0011] Further, the software dependency relationship automatic integration method based on metapackage further includes the step of: S5, performing full-link trust verification on the build link to ensure the integrity and trustworthiness of the process from source code to system construction; wherein performing full-link trust verification on the build link includes the following steps: S51, starting from the hardware trust root, performing cryptographic measurement on each stage of the build link to form a progressive trust verification chain; the verification of each stage is based on the trusted state of the previous stage to ensure that any tampering will be detected and the subsequent process will be blocked; S52, integrating a dynamically updatable verification strategy library to automatically check the build environment, dependency source, and integrity; the verification strategy supports dynamic loading and updating through an interface; and S53, storing evidence of key verification, binding the measurement hash value, digital signature, and timestamp of each stage, and writing them into a distributed ledger, and aggregating to generate a global integrity proof to ensure that the evidence data cannot be tampered with.

[0012] Further, the software dependency relationship automatic integration method based on metapackage further includes the step of: S6, verifying the application binary interface compatibility of shared dependency libraries through binary fingerprint comparison to block the integration of incompatible versions; wherein verifying the application binary interface compatibility of shared dependency libraries through binary fingerprint comparison includes the following steps: S61, extracting the cryptographic hash value of the key application binary interface elements of the shared dependency library to be integrated as a binary fingerprint; S62, comparing the extracted binary fingerprint with the baseline fingerprint of the tested compatible version in the trusted database; and S63, when the comparison result shows that the key application binary interface is incompatible, automatically blocking the integration process and generating a diagnostic report.

[0013] In a second aspect, the application provides a software dependency automation integration system based on metapackaging, which is applied to an embedded Linux construction system, and the system comprises:

[0014] A metapackaging framework construction module is configured to create a metapackaging framework in the embedded Linux construction system and define a construction hook containing resource injection and dependency aggregation functions through a Makefile.

[0015] A resource injection module is configured to deploy precompiled software packages and shared dependency libraries to a target directory of the construction system through an automation script.

[0016] A dependency resolution module is configured to parse metadata of the precompiled software packages to extract dependency information and generate a global dependency list based on a topological sorting algorithm.

[0017] A dependency configuration module is configured to write the global dependency list to a dependency declaration configuration of the metapackaging.

[0018] A dynamic dependency arbitration module is configured to solve dependency conflict and circular dependency problems, comprising: a conflict detection submodule configured to compare a Depends field in a metadata file with the global dependency list in real time to generate a conflict dependency pair set; a priority arbitration submodule configured to dynamically adjust a dependency order based on a preset conflict resolution strategy; and a version rollback submodule configured to automatically roll back to a historically compatible version and retrigger a dependency resolution process when the conflict cannot be automatically resolved.

[0019] A trusted verification module is configured to perform integrity verification and trusted evidence on a system construction link from source code.

[0020] A compatibility detection module is configured to verify application binary interface compatibility of shared dependency libraries through binary fingerprint comparison and block an integration process when incompatibility is detected.

[0021] A system integration unit is configured to integrate all modules into an automation integration system to realize closed-loop control of a construction process, adaptation of multiple construction systems, and visual analysis and tracing of construction logs.

[0022] The application has the following beneficial effects:

[0023] In a first aspect, the application adopts dynamic dependency aggregation, solves the sequence disorder problem caused by traditional static dependency declaration through a topological sorting algorithm and a conflict detection mechanism, improves construction success rate, adopts circular dependency blocking, integrates real-time detection of circular dependency, improves alarm accuracy, and avoids invalid construction, adopts ABI compatibility guarantee, intercepts runtime crashes caused by interface incompatibility through binary fingerprint comparison, and thus improves reliability of embedded system integration.

[0024] In a second aspect, the application improves the automation of the construction process and reduces the dependency analysis time through core processes such as resource injection and dependency analysis; reduces the configuration error rate by using an incremental update strategy to configure and adjust the changed dependencies; improves the parallel processing capability of the construction by supporting batch injection of multi-architecture dependency packages, thereby optimizing the construction efficiency of the embedded system.

[0025] In a third aspect, the application realizes tamper-proofing of the construction process by using full-link trusted verification based on a hardware trust root and a blockchain storage; and enhances the security of the embedded system construction by using digital signature verification to perform multi-hash value and GPG signature verification on the pre-compiled package to block the risk of malicious code injection.

[0026] In a fourth aspect, the application uses a standardized framework design to realize component decoupling through a hierarchical directory structure to reduce maintenance costs; and supports multiple construction systems by dynamically loading verification rules and priority strategies through dynamic strategy adaptation, thereby improving the maintainability and expandability of the embedded system construction. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 is a flowchart of a software dependency automatic integration method based on meta packaging provided by an embodiment of the application.

[0028] Figure 2 is a flowchart of a method for creating a meta packaging framework provided by an embodiment of the application.

[0029] Figure 3 is a flowchart of a resource injection mechanism method provided by an embodiment of the application.

[0030] Figure 4 is a flowchart of a method for realizing dynamic dependency aggregation provided by an embodiment of the application.

[0031] Figure 5 is a flowchart of an incremental update strategy method provided by an embodiment of the application.

[0032] Figure 6 is a flowchart of a method for performing full-link trusted verification provided by an embodiment of the application.

[0033] Figure 7 is a flowchart of a binary fingerprint comparison verification method provided by an embodiment of the application.

[0034] Figure 8 is a structural schematic diagram of a software dependency automatic integration system based on meta packaging provided by an embodiment of the application. DETAILED DESCRIPTION

[0035] The application will be further described below in conjunction with the drawings and specific embodiments.

[0036] With the development of embedded systems towards "modularization, lightweight, and scene-based", integrating third-party pre-compiled.ipk packages has become a core requirement in the firmware development of network devices such as routers and Internet of Things gateways based on OpenWrt. However, the traditional integration method of "meta-packaging + DEPENDS declaration" has two fatal flaws: dependency order confusion and metadata audit failure, resulting in low build success rate and high maintenance cost. To address these issues, this paper proposes an automatic integration method and system for pre-compiled software packages based on meta-packaging. By designing a "dynamic dependency aggregation" mechanism, the system uses build stage hooks and automated scripts to scan pre-compiled package metadata in real-time during the build process, generates a global dependency relationship list, and overwrites the DEPENDS declaration of meta-packaging. At the same time, it injects pre-compiled package entities and shared dependency resources to ensure the reliability of the build and packaging stages. This method improves the build success rate and shortens the dependency resolution time, effectively reducing the cost of manual maintenance and addressing the pain points of pre-compiled software package integration in embedded firmware development.

[0037] To achieve build process automation, improve dependency resolution accuracy, and ensure compatibility with pre-compiled software packages from different sources, please refer to Figure 1 The present application provides an automatic integration method for software dependencies based on meta-packaging, which includes the following steps: S1, creating a meta-packaging framework in an embedded Linux build system, the framework defines build stage hooks through a Makefile file, the hooks include resource injection scripts and dependency aggregation scripts; S2, automatically deploying pre-compiled software packages and shared dependency libraries to the target directory of the build system through the resource injection script; S3, parsing the metadata file of the pre-compiled software package, extracting dependency relationship information, and generating a global dependency relationship list based on the topological sorting algorithm of directed acyclic graphs; S4, using the dependency aggregation script to write the global dependency relationship list back to the dependency declaration configuration of meta-packaging.

[0038] Specifically, meta-package is a classic solution to multi-package integration, which integrates multiple packages by declaring dependencies. However, existing meta-package methods rely on static DEPENDS declaration and cannot handle dynamically changing dependencies, such as dependency changes after third-party package updates. In the OpenWrt build system, meta-package Meta-Package is defined by Makefile. The present application extends the build stage hook Hook of Makefile to realize the creation and hook definition of the meta-package framework, including the following steps: a. Define the meta-package structure, create the meta-package directory in the OpenWrt SDK, including the following files: Makefile, which defines the build rules and hooks; scripts, which store automated scripts; config.in: configuration option file. b. Inject the build stage hook, define the Build / InstallDev hook in Makefile to trigger resource injection and dependency aggregation. c. Configure the dependency relationship, add configuration options in config.in to allow developers to check the software package set that needs to be integrated, so as to embed the dependency management logic into the build process through the hook mechanism and realize "one check, automatic integration". Further, the Makefile of the meta-package can be optimized. In the Build / InstallDev hook, error handling logic is added to ensure that the build terminates when the script fails.

[0039] The traditional method needs to manually copy the precompiled software package to the build directory. The present application realizes the automatic batch injection of precompiled software packages through scripts, including the following steps: a. Define the resource path, including the precompiled package storage path and the build system target path; b. Write injection scripts to automatically identify the target architecture and the temporary directory of the build system; c. Execute permissions and integration, including adding execution permissions to the script and calling the script in Makefile; so as to automatically complete the deployment of 100+ precompiled software packages and shared libraries, reducing manual operation errors. In addition, in order to enhance the robustness of the script, path verification can be added at the beginning of the script when writing the injection script to avoid failure due to non-existent directory.

[0040] The.packageinfo file of OpenWrt stores package dependency information, but the format is unstructured text, which needs to be parsed and aggregated. The metadata parsing and dynamic dependency aggregation of the present application includes the following steps: a. Parsing the metadata file, including target file path and key field extraction; b. Writing aggregation scripts, including filtering irrelevant characters, removing duplicates; extracting dependency names; c. Writing dependency declarations: covering the contents of global_deps.txt to the Makefile of the meta package, replacing the original DEPENDS field. This scheme dynamically generates a dependency list through dynamic dependency aggregation, solving the problem of build failure caused by incorrect dependency order in traditional methods.

[0041] Dependency conflicts are the main cause of build failure. The present application solves conflicts through dependency injection and conflict resolution mechanism to achieve priority strategy and automatic verification. The implementation steps include: a. Dependency priority configuration, defining the whitelist of key packages in config.in; b. Writing conflict detection scripts; c. Dynamically adjusting the dependency order by inserting priority sorting logic in aggregate.sh; thereby solving the dependency conflict problem through priority strategy and improving the success rate of building.

[0042] To prevent malicious code injection and tampering, the present application builds the credibility of the construction process through full-link trusted verification. The implementation steps include: a. Generating material files, including recording source code version information and generating signature files. b. Recording product files, mainly calculating the hash value of the software package. c. Embedding construction logs, recording key commands to log files. d. Device-side verification, deploying opkg-in-toto plug-ins to automatically verify the integrity of materials, products and logs. The present application uses full-link trusted verification through hash value and signature verification to ensure that the construction process has not been tampered with, meeting the safety requirements.

[0043] Different versions of shared libraries may cause program runtime exceptions. The present application detects ABI compatibility (application binary interface compatibility) through binary compatibility detection. The implementation steps include: a. Generating ABI fingerprints: using the abidw tool to extract ABI information from.so files. b. Comparing compatibility, including using abidiff to analyze the differences between old and new versions and determining the compatibility level, whether to allow upgrade or block construction. c. Blocking mechanism, setting threshold in scripts. The present application blocks runtime crashes caused by ABI incompatibility to ensure firmware stability.

[0044] Through the creation of the above-mentioned meta packaging framework and the definition of hooks, the automatic injection of pre-compiled packages, metadata parsing and dynamic dependency aggregation, full-link trusted verification, binary compatibility detection, the present application realizes the automation of the construction process, improves the accuracy of dependency resolution, blocks attack surfaces through full-link trusted verification to improve security, and ensures smooth upgrade of cross-version firmware to achieve compatibility.

[0045] To change the dependency management from manual experience-driven to code algorithm-driven, and provide standardized and reliable underlying support for modular development of embedded system modules, refer to Figure 2 The application provides a method for creating a meta packaging framework, including the steps: S11, creating a directory structure of the meta packaging framework, including a Makefile file for defining build rules and hooks, a scripts directory for storing resource injection and dependency aggregation scripts, a config directory for storing configuration parameters, and a metadata directory for saving pre-compiled software package metadata templates; S12, defining build stage hooks in the Makefile, including hooks for triggering resource injection and dependency aggregation, hooks for environment initialization before building, and hooks for cleaning up temporary files and intermediate products; S13, writing resource injection automation scripts for copying pre-compiled software packages to the target directory of the build system, injecting shared dependency libraries into the system directory, and calling the script to perform the injection operation through the Makefile; S14, developing a dependency resolution script, extracting the Depends field by parsing the metadata, generating an acyclic dependency sequence using a topological sorting algorithm, and integrating a conflict detection mechanism to identify circular dependencies and generate an alarm log; S15, embedding a full-link trusted verification mechanism, including generating a material file by recording the source code version and build parameters, signing the pre-compiled software package hash value using a digital signature tool, and writing key build commands into a log file and calculating a hash check value to implement log integrity protection.

[0046] Specifically, around the creation of the meta packaging framework, through standardized directory structure design, multi-stage build hook integration, automated resource injection and dependency resolution, and full-link trusted verification mechanism, the pain points such as dependency management confusion, untrusted build process, and low efficiency of manual intervention in traditional embedded system construction are solved, and the specific solutions include: framework structuring, for the first time proposes a hierarchical directory structure such as Makefile, scripts, config, metadata, realizes decoupled management of build rules, script logic, configuration parameters and metadata, and improves the maintainability and extensibility of the framework; process automation, through multi-stage hooks such as resource injection, environment initialization, and cleaning, embeds dependency management, environment configuration, and other operations into the build process, reduces manual intervention, and reduces the error rate of operations; dependency intelligentization, combined with a topological sorting algorithm and a conflict detection mechanism, dynamically generates an acyclic dependency list, solves the sequence disorder and circular dependency problems caused by traditional static dependency declaration; safe and traceable, through material file generation, digital signature, and log evidence, realizes full-link trusted verification of the build process, and blocks the risk of malicious tampering and dependency version confusion.

[0047] In the embedded Linux build system, a hierarchical directory structure is created to standardize the component layout of the meta-packaging framework through the design of the directory structure of the meta-packaging framework. Specifically, the Makefile file, as the core of the build rule, defines the Build / InstallDev resource injection and dependency aggregation, Build / Prepare environment initialization, Build / Clean temporary file cleaning, and other hook entries, and introduces a standard rule library of the build system to ensure compatibility with the native build process. The Scripts directory includes the inject resource injection and aggregate dependency aggregation subdirectories, which store automation scripts. The scripts in the inject directory are responsible for batch migration of precompiled packages and shared libraries, and the scripts in the aggregate directory handle dependency relationship analysis and conflict detection. The Config directory stores config.in configuration files, which define dependency white lists, target architectures such as armhf and x86_64, and support dynamic adjustment of build strategies through the make menuconfig interface. The Metadata directory saves metadata templates such as.packageinfo files for precompiled software packages, and the templates define standardized Depends field formats for dynamic filling of dependency information by automation scripts. The directory structure of the meta-packaging framework is designed hierarchically, with clear responsibilities of framework components, supporting quick adaptation to new scenarios such as adding new architectures or dependency types, and reducing maintenance costs.

[0048] The automation of resource injection is achieved through the automation scripts in the inject directory for batch deployment of precompiled packages and shared libraries. Specifically, the package replication logic scans all.ipk files in the specified directory such as. / ipk_files / , and copies them to the package repository directory of the build system according to the target architecture, ensuring that the package and architecture tags match. Shared library injection identifies dynamic link dependencies such as libjy_lib.so in precompiled packages, copies them to the system directory, and records the association between the package and the dependent library during the injection process to generate a dependency matrix for subsequent analysis. The present application achieves the automated deployment of precompiled packages and shared libraries through the automation of resource injection, ensuring consistency between the versions of dependent libraries and target packages, and avoiding build failures due to missing dependencies.

[0049] In summary, the present application realizes the technical effects including: a. Dependency management automation: through topological sorting algorithm and conflict detection mechanism, a loop-free dependency list is dynamically generated, solving the problem of build failure caused by incorrect dependency order in traditional methods. b. Build process standardization: through Makefile hook and script encapsulation, the standardization of resource injection, dependency aggregation, environment initialization and other operations is realized. c. Security enhancement: through material file generation, digital signature and log integrity protection, the credibility and tamper resistance of the build process are ensured. d. Improved maintainability: through configuration parameter separation and metadata templating management, the manual maintenance cost is reduced, and multi-scenario rapid adaptation is supported.

[0050] To effectively solve the build interruption problem caused by missing dependencies in traditional resource injection, improve the reliability of automated integration, and reduce the cost of manual troubleshooting, please refer to Figure 3 The present application proposes a resource injection mechanism based on anchor point detection and timeout control. The resource injection script automatically deploys the pre-compiled software package and shared dependent library to the target directory of the build system. The resource injection mechanism is implemented through the following steps: S21, insert an anchor point detection function in the initialization stage of the pre-compiled software package installation script. This function detects the injection status of the shared dependent library in the target directory in real time through a polling mechanism; S22, define a dependency waiting function. Based on the output result of the anchor point detection function, verify the integrity and interface compatibility of the shared dependent library at runtime; S23, set a configurable timeout threshold. When the dependency waiting function does not detect the readiness of the dependent library within the threshold time, automatically trigger the termination of the installation process and generate an error report.

[0051] Specifically, the resource injection mechanism is based on anchor point detection and timeout control, which realizes real-time state monitoring and compatibility verification of shared dependent libraries by embedding dynamic detection logic in the pre-compiled package installation script. The dynamic dependency detection logic embedded in the installation script of the pre-compiled software package includes: anchor point detection function injection, inserting a detection function in the initialization stage of the installation script, checking whether the shared dependent library exists in the target directory through periodic polling, the polling interval can be configured or set by default, and dynamic adjustment is supported through environment variables. Dependency waiting and verification, define a dependency waiting function, after the anchor point detects that the dependent library exists, further verify its integrity and interface compatibility, if the dependent library version does not match, trigger an alarm and record the log. Timeout control and error handling, set a timeout threshold such as 120 seconds, if the dependent library is not ready within the time limit, automatically terminate the installation process; generate a diagnostic report containing error codes, dependency status and current system environment for developers to quickly locate the problem. By implementing the resource injection mechanism, the build interruption rate can be reduced, the dependency verification accuracy can be improved, and cross-platform deployment can be supported, compatible with OpenWrt / Yocto build system.

[0052] To solve the order sensitivity problem of traditional static dependency declaration, significantly improve the build success rate in complex scenarios, and reduce the cost of manual intervention, please refer to Figure 4 In step S3, based on the directed acyclic graph topological sorting algorithm to generate a global dependency list, the dynamic dependency aggregation method includes the following steps: S31, constructing a pre-compiled software package dependency graph, wherein the nodes represent pre-compiled software packages, and the edges represent the dependency relationship between pre-compiled software packages; S32, performing topological sorting on the dependency graph to generate an initial sequence that satisfies the dependency order; S33, optimizing and adjusting the initial sequence according to the preset priority parameter; S34, output the optimized dynamic aggregation global dependency list.

[0053] Specifically, in the embedded Linux build system, the scheme proposes a dynamic dependency aggregation algorithm based on topological sorting. By constructing the dependency graph of pre-compiled software packages and combining priority optimization strategies, a global dependency list that meets the cross-compilation constraints is generated. The dynamic dependency aggregation is achieved through the following process: (1) Dependency graph construction: parse the metadata files of all pre-compiled software packages and extract the Depends field; construct a directed acyclic graph, where nodes represent software packages and edges represent dependency relationships, supporting multiple architectures and version tags. (2) Topological sorting and optimization: use the improved Kahn algorithm to generate an initial dependency sequence, ensuring no circular paths; adjust the sequence based on pre-set priority parameters such as forced system library priority loading and high-version dependency degradation; support dynamic setting of the loading order of key packages through configuration files. (3) Conflict detection and output: detect circular dependency relationships (such as package A -> package B -> package A), generate an alarm log and interrupt the build; output the optimized global dependency list, covering the cross-compilation toolchain path and architecture tags, for direct invocation by subsequent build stages. This scheme applies dynamic dependency aggregation to embedded system firmware integration scenarios, improving dependency parsing accuracy and build success rate; supports dynamic priority adjustment, meeting the multi-scenario deployment needs of complex devices such as industrial gateways.

[0054] Specifically, the improved Kahn algorithm is used to describe the dependency relationships of pre-compiled software packages by constructing a directed acyclic graph. The algorithm first initializes the in-degree table to count the number of dependencies for each node, and then uses a priority queue to dynamically schedule the processing order of nodes. The priority adjustment is defined by a configuration file that assigns a high priority to key packages. Cross-compilation verification only processes dependency package versions that match the target architecture. When multiple dependency versions conflict, the version that is compatible with the majority of packages in the dependency chain is selected. Dynamic adjustment adjusts the in-queue timing of low-priority packages based on real-time build resources. The algorithm updates the in-degree of downstream nodes each time a node is dequeued, and generates an initial dependency sequence through topological sorting. A circular dependency detection mechanism is embedded to terminate the build and issue an alarm if a circular dependency is found. This scheme balances the logicality of dependency order and the constraints of the build environment, significantly improving the success rate of dependency parsing in complex scenarios.

[0055] To solve the configuration redundancy problem caused by traditional full replacement, improve the update efficiency and accuracy of dependency declaration, and reduce the build risk caused by configuration errors, please refer to Figure 5In step S4, the global dependency list is written back to the meta package dependency declaration configuration by using a dependency aggregation script, so as to adopt an incremental update strategy, which specifically includes the following steps: S41, parsing the original dependency declaration in the meta package configuration file, extracting existing dependencies to generate a benchmark dependency set; S42, comparing the global dependency list with the benchmark dependency set to identify new dependencies, obsolete dependencies and version conflicts; S43, based on the comparison result, reconstructing the dependency declaration configuration by using an incremental update strategy.

[0056] Specifically, in the OpenWrt construction system, the above-mentioned dependency declaration reconstruction strategy based on incremental update is proposed, and the seamless connection of the global dependency list and the meta package configuration is realized by a three-step method: a. benchmark dependency extraction, parsing the original DEPENDS field in the meta package Makefile, extracting the existing dependency list; generating a benchmark set to record the version label and architecture constraint. b. dependency difference comparison, comparing the global dependency list with the benchmark set; identifying new dependencies and judging whether there is a version conflict with obsolete dependencies. c. incremental update execution, retaining the original configuration of unchanged dependencies; appending new dependencies in the Makefile, and upgrading the version of obsolete dependencies; generating an optimized dependency declaration. The dependency declaration strategy improves the update efficiency of the dependency declaration, reduces the configuration error rate, and supports automatic adaptation of version compatibility.

[0057] Further, in order to solve the pain points of trust fault, verification rigidity and evidence tamperability in traditional construction, and provide a trusted delivery basis for high-security scenarios, please refer to Figure 6 The present scheme proposes a full-link trusted verification mechanism based on hardware trust root and distributed ledger, which realizes a trusted closed loop of the construction process through progressive cryptography measurement, dynamic verification strategy library and tamper-proof evidence storage technology. The present meta package-based software dependency relationship automatic integration method further includes the following steps: S5, performing full-link trusted verification on the construction link to ensure the integrity and trustworthiness of the process from source code to system construction; wherein performing full-link trusted verification on the construction link includes the following steps: S51, starting from the hardware trust root, performing cryptography measurement on each stage of the construction link to form a progressive trusted verification chain; the verification of each stage is based on the trusted state of the previous stage, so that any tampering will be detected and blocked in the subsequent process; S52, integrating a dynamically updatable verification strategy library to automatically check the construction environment, dependency source and integrity; the verification strategy supports dynamic loading and updating through an interface; S53, storing the key verification evidence, binding the measurement hash value, digital signature and timestamp of each stage, and writing them into a distributed ledger, and aggregating to generate a global integrity proof to ensure that the evidence data is tamper-proof.

[0058] Specifically, in the embedded firmware construction system, the full-link trusted verification is implemented through the following processes: (1) Hardware root of trust initialization, a unique hardware identifier is generated by the chip at startup, serving as the root anchor point of the trust chain; Bootloader is measured, and the hash value is expanded to the PCR register to ensure the trustworthiness of the startup environment. (2) Progressive verification chain execution, including: source code stage, calculating the SHA-3 hash value of the Git repository snapshot and binding it with the hardware PCR value; build stage, performing digital signature verification on the cross-compilation tool chain, allowing only tools within the whitelist to participate in compilation; dependency injection stage, performing integrity check on the pre-compiled package and rejecting abnormal packages without signature. (3) Dynamic policy library integration, dynamically loading verification policies through REST API; automatically switching verification strength according to the target environment. (4) Evidence preservation and proof generation, packaging the hash value, signature, timestamp, and policy version number of each stage into an evidence unit; writing the evidence unit into the blockchain through Hyperledger Fabric to generate an integrity proof file containing the Merkle tree root.

[0059] To solve the problem of runtime crash caused by ABI incompatibility in traditional dependency management, improve firmware stability, and reduce maintenance cost, please refer to Figure 7 The meta-packaged-based software dependency relationship automatic integration method further includes the steps of: S6, verifying the application binary interface compatibility of the shared dependency library through binary fingerprint comparison, and blocking the integration of incompatible versions; wherein verifying the application binary interface compatibility of the shared dependency library through binary fingerprint comparison includes the following steps: S61, extracting the cryptographic hash value of the key application binary interface element of the shared dependency library to be integrated as a binary fingerprint; S62, comparing the extracted binary fingerprint with the benchmark fingerprint in the trusted database that has been tested for compatibility; S63, when the comparison result shows that the key application binary interface is incompatible, automatically blocking the integration process and generating a diagnostic report.

[0060] Specifically, in the embedded Linux construction system, ABI compatibility verification is implemented through the following processes: (1) ABI fingerprint extraction, using the abidw tool to parse the ELF file of the shared library, extracting the hash value of the ABI key elements such as the exported symbol table and function parameter type, and generating a binary fingerprint; the fingerprint is bound and stored with the package version and architecture tag. (2) Benchmark fingerprint library construction, in the automated testing environment, execute the same fingerprint extraction process on the known compatible dependency library versions to generate a benchmark fingerprint library; mark key interface changes through manual review. (3) Compatibility comparison and blocking, in the integration stage, compare the fingerprint of the library to be integrated with the benchmark library, if new / additional symbols or types are found to be mismatched, it is determined to be incompatible; trigger the blocking mechanism to terminate the construction process and generate an alarm report containing conflict details.

[0061] The following is another embodiment of the meta-bundling-based pre-compiled software package automated integration method, which is characterized by processing complex dependency relationships and file injection tasks through a special meta-bundle and its associated automated scripts. The specific method is as follows: taking the integration of an internal package set named VTJZNVNS in the OpenWrt SDK environment as an example, the present application is specifically described. The set contains multiple.ipk packages, which are mutually dependent and jointly dependent on libraries such as libjy_lib.so.

[0062] Step 1: Create vtjznvns-bundle meta-bundle and automated scripts.

[0063] Create a package named vtjznvns-bundle, and the core Build / InstallDev part of its Makefile defines the entry of the execution script. At the same time, prepare a set of shell and perl scripts for performing subsequent file copying and dependency analysis tasks.

[0064] Step 2: Execute script to inject resources.

[0065] The automated script first copies all.ipk files stored in the ipk_files / directory to the $(OUTPUT_DIR) / packages / $(ARCH_PACKAGES) / VTJZNVNS / directory. Then, copy the public library libjy_lib.so and related header files from the source staging_dir to the temporary staging directory of the meta-bundle for injection during build.

[0066] Step 3: Execute script to dynamically generate DEPENDS.

[0067] The script executes the following command to aggregate dependencies:

[0068] find tmp / info-type f -name".packageinfo-feeds_VTJZNVNS_*"-exec grep"^Depends:"{}+|sed's / ^.*Depends: / / '|...|xargs...>depends_list.txt.

[0069] The command will find all the meta information files of VTJZNVNS packages, extract the Depends line, and after a series of text processing, deduplicate, sort, and format, finally generate a complete dependency list depends_list.txt. Then, the script uses the perl command to update the contents of depends_list.txt to the Makefile file of vtjznvns-bundle.

[0070] Fourth step: build firmware. The developer enters make menuconfig, and in the VTJZNVNS category, only checks vtjznvns-bundle. Then execute make. The build system will correctly process all.ipk packages in order due to the complete DEPENDS list dynamically written in vtjznvns-bundle, and finally install them and their dependent library files correctly into the firmware.

[0071] Compared with the background art, the above embodiment has the following significant beneficial effects: (1) high reliability, fundamentally solving the dependency problem: by dynamically aggregating the dependencies of all sub-packages and updating them to the meta package, it ensures that the build system can obtain a complete dependency view, and completely solves the cannot find dependency error caused by improper processing order. At the same time, by injecting shared library resources, it ensures that the dependency audit in the packaging phase can pass. (2) High automation, greatly improving integration efficiency: the entire integration process is automated by scripts, and developers do not need to manually create and maintain virtual Makefiles for dozens of packages, nor do they need to worry about the complex dependencies between them, greatly reducing the possibility of human error and operation. (3) Management is simplified, providing a "one-click switch": the integration of a large and complex software package set is abstracted into a single meta package. Developers only need to check this option in the configuration to complete the integration of the entire product line, greatly reducing the mental burden of using and maintaining the software set. (4) High degree of engineering, easy to maintain: this method solidifies the dispersed integration knowledge and operations into code and scripts, forming a clear and reproducible engineering solution. When the precompiled package set is updated, you only need to run the automated script again, and the maintainability is strong.

[0072] Please refer to Figure 8The application also provides a meta-packaging-based software dependency automatic integration system, which is applied to an embedded Linux construction system, and the system comprises: a meta-packaging framework construction module, which is used to create a meta-packaging framework in the embedded Linux construction system and define a construction hook containing resource injection and dependency aggregation functions through a Makefile; a resource injection module, which is used to deploy pre-compiled software packages and shared dependency libraries to a target directory of the construction system through an automatic script; a dependency resolution module, which is used to parse metadata of the pre-compiled software packages to extract dependency information and generate a global dependency list based on a topological sorting algorithm; and a dependency configuration module, which is used to write the global dependency list back to a dependency declaration configuration of the meta-packaging.

[0073] The meta-packaging-based software dependency automatic integration system further comprises: a dynamic dependency arbitration module, which is used to solve dependency conflict and circular dependency problems, comprising: a conflict detection submodule, which is used to compare a Depends field in a metadata file with the global dependency list in real time to generate a conflict dependency pair set; a priority arbitration submodule, which is used to dynamically adjust a dependency order based on a preset conflict resolution strategy; a version rollback submodule, which is used to automatically roll back to a historical compatible version and retrigger a dependency resolution process when the conflict cannot be automatically solved; a trust verification module, which is used to perform integrity verification and trusted evidence on a construction link from source code to a firmware file system; a compatibility detection module, which is used to verify application program binary interface compatibility of shared dependency libraries through binary fingerprint comparison and block an integration process when incompatibility is detected; and a system integration unit, which is used to integrate all the modules into an automatic integration system to realize closed-loop control of a construction process, adaptation of multiple construction systems, and visualized analysis and tracing of construction logs.

[0074] Specifically, the system described above builds an automatic solution covering the whole life cycle of dependency management through modularized integration design. In an OpenWrt construction system, a meta-packaging framework defines Build / InstallDev hooks through a Makefile to realize automatic linkage of resource injection scripts and dependency aggregation scripts. The dependency resolution module generates an acyclic dependency sequence in combination with cross-compilation constraints by using an improved Kahn algorithm; the dynamic dependency arbitration module adjusts a dependency order through a priority queue, and the version rollback submodule automatically rolls back to a historical compatible version when a conflict occurs. The trust verification module performs hash measurement and digital signature on key nodes of a construction link, and evidence data is aggregated and written into a Hyperledger Fabric blockchain; the compatibility detection module extracts ABI fingerprints of shared libraries by using an abidw tool and blocks incompatible integration after comparison with benchmark libraries. The system integration unit adapts multiple construction systems through standardized interfaces, a Web visualized interface displays dependency topology graphs and construction log tracing information in real time, and realizes closed-loop management and control of “configuration-construction-verification”.

[0075] Many modifications and variations of the described implementations are possible, and all such modifications and variations are intended to be within the scope of the present disclosure, as defined by the appended claims.

[0076] It should be noted that the above-mentioned embodiments are only some of the embodiments of the present application, but not all of them. The singular forms "a", "an" and "the" used in the embodiments and the appended claims are intended to include plural forms, unless the context clearly indicates otherwise.

Claims

1. A method for automated integration of software dependencies based on meta- packaging, characterized in that, Comprising the following steps: S1, creating a meta packaging framework in an embedded Linux build system, the framework defining build stage hooks through Makefile files, the hooks including resource injection scripts and dependency aggregation scripts; wherein the method of creating the meta packaging framework comprises the steps of: S11, creating a directory structure of the meta packaging framework, the directory structure including Makefile files for defining build rules and hooks, a scripts directory for storing resource injection and dependency aggregation scripts, a config directory for storing configuration parameters, and a metadata directory for saving pre-compiled software package metadata templates; S12, defining build stage hooks in the Makefile, including hooks for triggering resource injection and dependency aggregation, hooks for pre-build environment initialization, and hooks for cleaning up temporary files and intermediate products; S13, writing resource injection automation scripts for copying pre-compiled software packages to the target directory of the build system, injecting shared dependency libraries into the system directory, and invoking the scripts to perform injection operations through the Makefile; S14, developing dependency resolution scripts, extracting the Depends field by parsing the metadata, generating an acyclic dependency sequence using a topological sorting algorithm, and integrating a conflict detection mechanism to identify circular dependencies and generate warning logs; S15, embedding a full-link trusted verification mechanism, including recording source code versions and build parameters to generate material files, using a digital signature tool to sign pre-compiled software package hash values, and writing key build commands to log files and calculating hash check values to achieve log integrity protection; S2, automatically deploying pre-compiled software packages and shared dependency libraries to the target directory of the build system through the resource injection scripts; S3, parsing the metadata file of the pre-compiled software package, extracting dependency relationship information, and generating a global dependency relationship list based on a directed acyclic graph topological sorting algorithm; S4, using the dependency aggregation script to write the global dependency relationship list back to the dependency declaration configuration of the meta package.

2. The method of claim 1, wherein, In step S2, the resource injection scripts automatically deploy pre-compiled software packages and shared dependency libraries to the target directory of the build system, and the resource injection mechanism is implemented through the following steps: S21, inserting an anchor detection function in the initialization stage of the pre-compiled software package installation script, the function detecting the injection status of shared dependency libraries in the target directory in real time through a polling mechanism; S22, defining a dependency waiting function, based on the output of the anchor detection function, verifying the integrity and interface compatibility of shared dependency libraries at runtime; S23, setting a configurable timeout threshold, when the dependency waiting function does not detect that the dependency library is ready within the threshold time, automatically triggering the termination of the installation process and generating an error report.

3. The method of claim 1, wherein, In step S3, the directed acyclic graph topological sorting algorithm generates a global dependency relationship list, including the following steps: S31, building a pre-compiled software package dependency relationship graph, where nodes represent pre-compiled software packages and edges represent dependency relationships between pre-compiled software packages; S32, performing a topological sorting on the dependency graph to generate an initial sequence satisfying the dependency order; S33, optimizing and adjusting the initial sequence according to a preset priority parameter; S34, outputting the optimized dynamic aggregated global dependency list.

4. The method of claim 1, wherein, The step S4 specifically includes the following steps: S41, parsing the original dependency declaration in the meta packaging configuration file to extract existing dependencies to generate a benchmark dependency set; S42, comparing the global dependency relationship list with the benchmark dependency set to identify new dependencies, obsolete dependencies, and version conflicts; S43, based on the comparison result, using an incremental update strategy to reconstruct the dependency declaration configuration.

5. The method of claim 1, wherein, The method further includes the following steps: S5, performing full-link trusted verification on the build link to ensure the integrity and trustworthiness of the process from the source code to the system build; The full-link trusted verification on the build link includes the following steps: S51, starting from the hardware trust root, performing cryptographic measurement on each stage of the build link to form a progressive trusted verification chain; The verification of each stage is based on the trusted state of the previous stage, ensuring that any tampering will be detected and blocked in the subsequent process; S52, integrating a dynamically updatable verification strategy library to automatically check the build environment, dependency source, and integrity; the verification strategy supports dynamic loading and updating through an interface; S53, storing the key verification evidence by binding the measurement hash value, digital signature, and timestamp of each stage to a distributed ledger, and aggregating to generate a global integrity proof to ensure that the evidence data cannot be tampered with.

6. The method of claim 1, wherein, The method further includes the following steps: S6, verifying the application binary interface compatibility of the shared dependency library by binary fingerprint comparison to block the integration of incompatible versions; The binary fingerprint comparison to verify the application binary interface compatibility of the shared dependency library includes the following steps: S61, extracting the cryptographic hash value of the key application binary interface element of the shared dependency library to be integrated as a binary fingerprint; S62, comparing the extracted binary fingerprint with the benchmark fingerprint tested for compatibility in the trusted database; S63, when the comparison result shows that the key application binary interface is incompatible, automatically blocking the integration process and generating a diagnostic report.

7. A software dependency automation integration system based on meta-packaging, applied to an embedded Linux build system, characterized in that, The system includes: A meta packaging framework building module for creating a meta packaging framework in an embedded Linux build system and defining a build hook containing resource injection and dependency aggregation functions through a Makefile; wherein the meta packaging framework building module is specifically configured to: a. create a directory structure of the meta packaging framework, including a Makefile file for defining build rules and hooks, a scripts directory for storing resource injection and dependency aggregation scripts, a config directory for storing configuration parameters, and a metadata directory for saving precompiled software package metadata templates; b. define build stage hooks in the Makefile, including hooks for triggering resource injection and dependency aggregation, hooks for environment initialization before building, and hooks for cleaning up temporary files and intermediate products; c. Write resource injection automation scripts to copy pre-compiled software packages to the target directory of the build system, inject shared dependency libraries into the system directory, and perform injection operations through Makefile calls; d. Develop dependency resolution scripts to extract the Depends field by parsing metadata, generate acyclic dependency sequences using topological sorting algorithms, and integrate conflict detection mechanisms to identify circular dependencies and generate warning logs; e. Embed full-link trusted verification mechanisms, including recording source code versions and build parameter generation material files, using digital signature tools to sign pre-compiled software package hash values, and writing key build commands to log files and calculating hash check values to protect log integrity; Resource injection module, for deploying pre-compiled software packages and shared dependency libraries to the target directory of the build system through automated scripts; Dependency resolution module, for parsing metadata of pre-compiled software packages to extract dependency information, and generating a global dependency relationship list based on topological sorting algorithms; Dependency configuration module, for writing the global dependency relationship list to the dependency declaration configuration of the meta package; Trusted verification module, for performing integrity verification and trusted evidence on the build link from source code to system; Compatibility detection module, for verifying the application binary interface compatibility of shared dependency libraries through binary fingerprint comparison, and blocking the integration process when incompatibility is detected; System integration unit, for integrating all modules into an automated integration system to achieve closed-loop control of the build process, adaptation to multiple build systems, and visual analysis and traceability of build logs.

8. The system of claim 7, wherein, The system further comprises: Dynamic dependency arbitration module, for resolving dependency conflicts and circular dependency problems, including: Conflict detection submodule, for real-time comparison of the Depends field in the metadata file and the global dependency list to generate a set of conflicting dependency pairs; Priority arbitration submodule, for dynamically adjusting the dependency order based on pre-set conflict resolution strategies; Version rollback submodule, for automatically rolling back to a historically compatible version and retriggering the dependency resolution process when conflicts cannot be automatically resolved.

Images