A binary dependency package management method, device and equipment

Abstract

The application discloses a binary dependency package management method, device and equipment, and relates to the technical field of software package management. The method comprises the following steps: analyzing a dependency declaration in a project configuration file; communicating with a central warehouse based on the dependency declaration to obtain metadata of a dependency package; making a dependency decision according to the metadata; performing corresponding acquisition and integration based on a determined dependency type; performing corresponding acquisition and integration based on a determined dependency type; and outputting error information and prompting a user to use local source code or other configuration sources for building if the central warehouse does not return a matched product. Dependency management automation, building security improvement and building process efficiency are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software package management, in particular to a binary dependency package management method, device and equipment. BACKGROUND

[0002] With the rapid development of modern software development, application programs increasingly rely on third-party libraries and frameworks. Package managers have become a core component in the development ecosystem, widely used for automating software dependency management, obtaining source code, and completing compilation and linking tasks. For example, tools such as Cargo for Rust language, npm for JavaScript, and pip for Python parse dependency lists, download source code from remote repositories or local paths, and build them, providing developers with highly automated dependency management capabilities.

[0003] The native package manager cjpm of the Warejci programming language also follows this pattern, and its main functions include obtaining source code from version control systems (such as Git) or local paths, and compiling and linking locally. However, this pure source code dependency management mode has several inherent limitations:

[0004] 1. Build efficiency bottleneck: For large or complex dependencies, compiling from source code each time consumes a lot of time. In continuous integration / continuous deployment (CI / CD) pipelines, this repeated compilation leads to low efficiency of the build process, affecting the speed of development iterations.

[0005] 2. Difficulty integrating closed-source components: Since dependency management relies entirely on source code acquisition methods, commercial libraries or closed-source components provided in binary form cannot be directly integrated, which limits the language's applicability in certain commercial application scenarios.

[0006] 3. Platform adaptation complexity: Binary compatibility management under different operating systems or hardware architectures requires manual handling by developers, which is prone to errors and difficult to ensure consistency between environments.

[0007] At the same time, with the increasing complexity of the open source software ecosystem, software supply chain security issues are becoming increasingly prominent. Modern applications generally rely on a large number of third-party open source libraries, and these libraries may have known vulnerabilities, malicious code, or license compliance risks, thereby introducing potential security threats to the final application. Existing security audits or software composition analysis (SCA) tools usually scan after code submission, after build completion, or even before deployment. This post-detection mode has obvious lag: when risks are discovered, problem dependencies may have already been integrated and spread to multiple versions, resulting in high repair costs and prolonging the exposure time of security threats.

[0008] Therefore, there is an urgent need in this field for a binary dependency package management method that can overcome the above-mentioned defects. Summary of the Invention

[0009] The purpose of this invention is to provide a method, apparatus, and device for managing binary dependency packages. During the build process, it automatically selects safe binary artifacts or prompts users to upgrade to safe versions, effectively avoiding the use of high-risk dependencies. It automatically performs downloading, integrity verification, cache management, and build integration based on dependency type, without manual intervention. It also provides rollback and user intervention mechanisms, ensuring a controllable build process even if the central repository does not provide a matching artifact. These combined technical features achieve automated dependency management, improved build security, and a more efficient build process.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] In a first aspect, the present invention provides a method for managing binary dependency packages, the method comprising:

[0012] Parse dependency declarations in the project configuration file; dependency declarations use a uniform syntax format to define dependency package names and version constraints, without explicitly distinguishing between source code dependencies and binary dependencies;

[0013] Based on dependency declarations, it communicates with the central repository to obtain metadata of dependency packages; the metadata includes available version information, dependency type information, and security status information.

[0014] Make dependency decisions based on metadata;

[0015] Dependency decisions are made based on metadata, including: when a binary artifact that conforms to version constraints, is suitable for the current platform, and is in a secure state, determining that the dependency package is a binary dependency; when the requested version does not exist but an updated version that conforms to semantic version constraints exists, prompting the user with update information and requesting confirmation; when the requested version is marked as high risk, refusing to build and outputting an error message containing risk details and remediation suggestions.

[0016] Based on the defined dependency type, perform the corresponding fetching and integration, including: for binary dependencies, download the artifact from the central repository, perform integrity verification, and then link it to the build process; for source code dependencies, download the source code package and perform compilation and linking during the build phase.

[0017] If the central repository does not return a matching artifact, an error message will be output, prompting the user to build using local source code or other configuration sources.

[0018] In some embodiments, based on dependency declarations, communication with the central repository is used to obtain metadata of dependency packages, including:

[0019] sending a dependency metadata query request, the request including dependency package name, version constraint, and target platform triplet information;

[0020] receiving JSON format response data returned by the central repository, the response data including version list, artifact type, platform compatibility information, security status, and recommended version information.

[0021] In some embodiments, the dependency decision is made according to the metadata, including:

[0022] when the security status field in the metadata is marked as “high_risk”, the build is automatically rejected, and an error prompt message with a security notification number, risk description, and recommended repair version is generated;

[0023] when the security status is “clean” or “low_risk”, the build is allowed to continue execution.

[0024] In some embodiments, integrity verification is performed, including:

[0025] After downloading the artifact, the SHA256 checksum of the local file is calculated and compared with the checksum value returned by the central repository. Only when the two are consistent, the artifact is allowed to enter the build process, otherwise the build is terminated and a verification failure prompt is output.

[0026] In some embodiments, the method further includes:

[0027] when the central repository returns a dependency package that provides both binary artifacts and source code artifacts, the type of dependency to be used is determined according to a preset strategy or user interaction input, and the preset strategy includes performance priority or security priority strategy.

[0028] In some embodiments, the method further includes:

[0029] The artifacts that pass the integrity verification are stored in the local cache and indexed for subsequent build reuse.

[0030] In a second aspect, the application also provides a binary dependency package management device, which includes:

[0031] a declaration parsing module for parsing dependency declarations in a project configuration file; the dependency declarations define dependency package names and version constraints in a unified syntax format, without explicitly distinguishing between source code dependencies or binary dependencies;

[0032] a data acquisition module for communicating with the central repository based on the dependency declarations to acquire metadata of the dependency packages; the metadata includes available version information, dependency type information, and security status information;

[0033] A dependency decision module is configured to make a dependency decision according to the metadata;

[0034] The dependency decision according to the metadata includes: determining the dependency package as a binary dependency when there is a binary artifact that meets the version constraint and is applicable to the current platform and the security status is safe; prompting the user with update information and requesting confirmation when the requested version does not exist but an updated version that meets the semantic version constraint exists; rejecting the build and outputting an error prompt containing risk details and repair suggestions when the requested version is marked as high risk;

[0035] An acquisition integration module is configured to perform corresponding acquisition and integration based on the determined dependency type; the corresponding acquisition and integration based on the determined dependency type includes: for a binary dependency, downloading the artifact from the central repository and performing integrity verification before linking it to the build process; for a source code dependency, downloading the source code package and performing compilation and linking in the build stage;

[0036] An information output module is configured to output error information and prompt the user to use local source code or other configuration sources for building if the central repository does not return a matching artifact.

[0037] In a third aspect, the present application further provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the binary dependency package management method provided in the first aspect when executing the computer program.

[0038] In a fourth aspect, the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executable on the processor to implement the binary dependency package management method provided in the first aspect.

[0039] In a fifth aspect, the present application further provides a computer program product, including a computer program, and the computer program is executable on the processor to implement the binary dependency package management method provided in the first aspect.

[0040] The binary dependency package management method has the beneficial effects that: the binary dependency package management method in the application first analyzes dependency declaration in a project configuration file; the dependency declaration defines dependency package name and version constraint in a unified syntax format, without explicitly distinguishing source code dependency or binary dependency; then, based on the dependency declaration, the application communicates with a central warehouse to obtain metadata of the dependency package; the metadata includes available version information, dependency type information and security state information; then, the application makes a dependency decision according to the metadata; the dependency decision according to the metadata includes: when there is a binary artifact that meets the version constraint and is suitable for the current platform and the security state is safe, the dependency package is determined to be a binary dependency; when the requested version does not exist and there is an updated version that meets the semantic version constraint, the application prompts the user with update information and requests confirmation; when the requested version is marked as high risk, the application rejects the build and outputs an error prompt containing risk details and repair suggestions; then, the application performs corresponding acquisition and integration based on the determined dependency type; the acquisition and integration based on the determined dependency type include: for binary dependency, the application downloads the artifact from the central warehouse and performs integrity verification, and then links the artifact to the build process; for source code dependency, the application downloads the source code package and performs compilation and linking in the build stage; if the central warehouse does not return a matching artifact, the application outputs error information and prompts the user to use local source code or other configuration sources for building. In the build process, the application automatically selects a safe binary artifact or prompts to upgrade to a safe version, effectively avoiding the use of high-risk dependencies; the application automatically performs download, integrity verification, cache management and build integration according to the dependency type, without manual intervention; at the same time, the application provides a fallback and user intervention mechanism, so that even if the central warehouse does not provide a matching artifact, the build process can still be controlled. The series of technical features comprehensively realize dependency management automation, build security improvement and build process efficiency.

[0041] The above description is only a summary of the technical scheme of the application. In order to more clearly understand the technical means of the application and to implement the content of the description, the following will describe the preferred embodiments of the application in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0042] Figure 1 A flowchart of a binary dependency package management method according to an embodiment of the application;

[0043] Figure 2 A flowchart of another binary dependency package management method according to an embodiment of the application;

[0044] Figure 3 A structural diagram of a binary dependency package management device according to an embodiment of the application;

[0045] Figure 4 A structural diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0046] The technical solutions of the present application will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0047] It should be noted that the description of "one embodiment", "embodiment", "example embodiment" and the like in the specification means that the described embodiment can include specific features, structures or characteristics, but not every embodiment must include these specific features, structures or characteristics. In addition, such expressions do not mean the same embodiment. Further, when a specific feature, structure or characteristic is described in connection with an embodiment, it is indicated that such a feature, structure or characteristic is combined into other embodiments within the knowledge of those skilled in the art, whether or not it is explicitly described.

[0048] In addition, the technical features involved in different embodiments of the present application described below can be combined with each other as long as there is no conflict.

[0049] In some embodiments, as shown in Figure 1 A binary dependency package management method is provided, and the specific method includes the following steps.

[0050] S101, parsing the dependency declaration in the project configuration file.

[0051] The dependency declaration defines the dependency package name and version constraint in a unified syntax format, without explicitly distinguishing between source code dependency or binary dependency. Dependency refers to the external code library or module required by a software project to complete compilation, testing or running. Binary dependency refers to a dependency package file (such as.so,.dll,.a file or packaged archive file) that has been pre-compiled and can be directly run or linked on a specific target platform without the need for recompilation from source code. Source code dependency refers to a dependency provided in the form of human-readable source code, which needs to be compiled into binary code by a local compiler before use.

[0052] It should be noted that the binary dependency package management method in the present application can be implemented based on Aura, which is a newly designed package manager.

[0053] Specifically, Aura reads the configuration file (such as aura.toml) from the project root directory and uses the built-in TOML syntax parsing engine to parse the file structure section by section. When the [dependencies] field is parsed, Aura automatically identifies the declaration form of each dependency, such as "zip4cj='1.0.5'", extracts the dependency package name and version constraint, and converts it into an internal unified data structure.

[0054] Unlike traditional package managers, the application adopts a unified dependency declaration syntax, and developers do not need to explicitly mark the type of dependency (such as source code dependency or binary dependency) in the configuration file. All dependencies are described in consistent syntax rules. Aura does not immediately determine the specific form of the dependency during parsing, but stores the parsed dependency as a "logical dependency" and only records its package name, version constraint, and pending status. This design makes dependency declaration more concise and provides a flexible foundation for subsequent dependency type determination and security verification.

[0055] After parsing, Aura builds an internal list of dependency objects, each containing dependency name, version constraint, and unconfirmed dependency type information. At this time, Aura does not directly download or build, but enters the next phase of dependency resolution, which is to communicate with the central repository to obtain dependency metadata. Through this parsing and delayed determination mechanism, Aura decouples dependency declaration and dependency resolution, significantly improving the generality and automation of the package management process, and laying a technical foundation for subsequent security decisions, version negotiation, and dependency artifact selection.

[0056] S102, based on the dependency declaration, communicating with the central repository to obtain the metadata of the dependency package.

[0057] Among them, the metadata includes available version information, dependency type information and security state information, and the central repository is a centralized storage server for storing and managing metadata and file content of software packages (including binary artifacts and source code).

[0058] Optionally, a dependency metadata query request can be sent first, including dependency package name, version constraint and target platform triple information; then receive the JSON format response data returned by the central repository, including version list, artifact type, platform compatibility information, security state and recommended version information.

[0059] Specifically, when the Aura package manager finishes parsing the dependency declaration in the configuration file, the system will automatically enter the stage of communication with the central warehouse to obtain the metadata information of each dependent package. This process is performed by the "central warehouse communication module" built into the package manager, which uses standardized RESTful API to interact with the remote central warehouse. Aura will construct a query request for each parsed dependency and send a metadata query request containing the dependent package name, version constraint, and target platform information to the central warehouse. For example, when the configuration file declares "zip4cj='1.0.5'", Aura will generate a request URL: https: / / demo.folib.com / api / v1 / packages / zip4cj / versions / 1.0.5 / artifacts?platform=x86_64-unknown-linux-gnu, and carry the authentication token and client identification information in the request header.

[0060] Upon receiving the request, the central warehouse will return a JSON-formatted response containing comprehensive metadata for the dependent package. The returned information includes the types of the version and compatible versions (such as binary, source, or both), the available platforms for each version, the corresponding download link, the SHA256 checksum, and the security status flag (such as clean, low_risk, high_risk). When a version has security risks, the response will also include security advisories (advisory) and recommended safe versions (recommended_version) to allow Aura to perform risk warnings and decision-making in subsequent steps. After receiving the response, Aura will parse and archive the returned metadata. For each dependent package, the system will map the query results to the internal dependency object, updating its type field, available version list, and security status. If the central warehouse returns multiple available versions, Aura will filter out the target version that best meets the conditions according to the version constraint and semantic versioning rules. If the version exists as a binary artifact and is compatible with the current platform, Aura will mark it as "binarypreferred"; if only source code artifacts exist, it will be marked as "sourcerequired". If the requested version does not exist, Aura will recommend an upgradeable version from the available_versions list returned by the central warehouse, and then prompt the user to confirm whether to upgrade in the terminal interface.

[0061] Through the above communication and analysis process, Aura can accurately learn the type, security status and available version of each dependent package before the build starts, realizing the automatic synchronization and controllable security of dependency metadata. This mechanism not only ensures the security and reliability of the artifacts used in the build process, but also avoids the tedious operation of manually judging the source and type of dependency, thereby significantly improving the intelligence and security protection level of the package manager.

[0062] S103, making a dependency decision according to the metadata.

[0063] Among them, making a dependency decision according to the metadata includes: when there is a binary artifact that meets the version constraint and is suitable for the current platform and the security status is safe, determining the dependent package as a binary dependency; when the requested version does not exist and there is an updated version that meets the semantic version constraint, prompting the user for update information and requesting confirmation; when the requested version is marked as high risk, refusing to build and outputting an error prompt containing risk details and repair suggestions.

[0064] Optionally, making a dependency decision according to the metadata includes: when the security status field in the metadata is marked as “high_risk”, automatically refusing to build and generating error prompt information with a security announcement number, risk description and recommended repair version; when the security status is “clean” or “low_risk”, allowing the build to continue execution.

[0065] Specifically, first, Aura will read the available version list and the attribute information of each version from the returned metadata, including artifact type (type), platform compatibility (platforms), security status (security_status) and the like. When it is detected that there is a binary artifact that meets the version constraint, is suitable for the current build platform and has a “clean” security status, Aura will automatically determine the dependency as a binary dependency without the need for the user to manually specify. At this time, the system will record the corresponding download link, verification information and target platform parameters, and prepare to enter the binary artifact download stage. This automatic identification mechanism makes it unnecessary to explicitly distinguish between source code dependencies and binary dependencies in the build process, significantly improving the automation level of dependency management.

[0066] Second, when the requested exact version does not exist in the metadata returned by the central repository, but an updated version that satisfies the semantic version constraint (e.g., ">=1.0.0,<2.0.0") exists, Aura will proactively trigger the "version negotiation" logic. The system will prompt the user with the update information in the terminal output, e.g., "The requested version 1.0.5 does not exist, detected version 1.0.7 is available, use it?" The user can confirm whether to upgrade to the recommended version through interaction. If the user agrees to upgrade, Aura will automatically modify the internal dependency resolution result and switch the subsequent process to download and build the updated version; if the user refuses, the system will keep the original version declaration and terminate the build to prevent the introduction of uncertain dependencies.

[0067] Finally, when the metadata returned by the central repository identifies a certain version as high-risk (e.g., "security_status": "high_risk"), Aura's security decision logic will take effect immediately. The system will automatically refuse to continue building and output serious warning information in the terminal, detailing the risk description (advisory) and repair suggestion (recommended_version). For example, in the case of high-risk vulnerabilities in zip4cj v1.0.5, Aura will output the following prompt:

[0068] error: [SECURITY RISK] Dependency `zip4cj v1.0.5` is flagged as HIGHRISK. Advisory: CVE-2025-XXXXX: Critical vulnerability in compression module.Recommendation: Upgrade to `zip4cj v1.0.7` or later.

[0069] --> aura.toml:5:1

[0070] Build aborted due to security policy.

[0071] The system will refuse to build at the same time, forcing the user to intervene manually to ensure that risky dependencies are not mistakenly used in project construction.

[0072] Through the above mechanism, Aura realizes intelligent and safe decision-making in dependency management. It not only automatically selects the optimal artifact in a multi-version, multi-platform scenario, but also actively discovers high-risk versions and performs build blocking and risk prompting, thereby building a dependency decision system with security self-adaptation capability. This technical solution effectively avoids the vulnerability risks caused by manual judgment errors, ensuring the safety and consistency of the build results.

[0073] Optionally, when the central warehouse returns a dependency package that provides both binary artifacts and source code artifacts, the type of dependency to be used is determined according to a preset strategy or user interaction input. The preset strategy includes a performance priority or a security priority strategy.

[0074] Specifically, first, after receiving the dependency metadata returned by the central warehouse, Aura compares the attributes of the two types of artifacts. The metadata usually includes information such as artifact type, supported platform, compilation target, signature hash, security rating, release time, etc. Aura determines the availability and priority of the artifacts based on this information. For example, if the compilation target of the binary artifact completely matches the current system platform, and its security rating is "safe" or "trusted", the system will prefer to use this artifact; if the binary artifact fails signature verification, lacks a security audit report, or has a version that is behind, it will enter the source code priority judgment branch.

[0075] In the preset strategy mode, Aura package manager can automatically execute selection logic according to user configuration files or system default values. If the "performance priority" strategy is enabled, the system will tend to select the binary artifact that has passed integrity verification to reduce compilation time and speed up the build; if the "security priority" strategy is enabled, Aura will still prefer to select the source code artifact even if the binary artifact is available, so as to perform compilation, audit and dependency integrity check locally, thereby maximizing security. This strategy can be set through configuration items in the aura.toml file (for example, [policy] prefer="security"), or temporarily overridden in a single build through command line parameters.

[0076] In the user interaction mode, Aura will actively prompt the developer when it detects the coexistence of binary and source code artifacts. For example, in the terminal output: "Dependency package foo@1.2.3 provides both binary and source code packages. Please select the dependency type: 1) Performance priority (binary) 2) Security priority (source code)." After the user inputs the selection, the system records the decision result and optionally caches it in the local configuration for reuse in subsequent decisions for the same dependency. If the user does not make a selection, Aura will make a decision based on the default strategy.

[0077] After the decision is made, Aura writes the selected artifact type into the dependency resolution result table and enters the subsequent acquisition and construction phase accordingly. For the selected binary artifact, Aura downloads the file from the central repository, verifies the hash value and digital signature, and then directly links it to the construction process. For the source code artifact, Aura performs source code pulling, recursive dependency resolution, and local compilation.

[0078] Through the above mechanism, the application realizes a dynamic dependency type decision-making process that can adaptively balance construction performance and supply chain security in different project scenarios. The technical effect is that:

[0079] On the one hand, through the strategic and interactive dependency decision, Aura avoids the static selection problem of traditional package managers in the binary artifact scenario, improving the flexibility and controllability of dependency resolution. On the other hand, this mechanism enables the package management process to automatically adjust the security policy according to user needs, effectively reducing system instability caused by binary artifact risks or compilation overhead, and significantly improving the security, transparency, and user experience of package management.

[0080] S104, performing corresponding acquisition and integration based on the determined dependency type.

[0081] Among them, performing corresponding acquisition and integration based on the determined dependency type includes: for binary dependencies, downloading the artifact from the central repository and performing integrity verification before linking it to the construction process; for source code dependencies, downloading the source code package and performing compilation and linking in the construction phase.

[0082] Optionally, performing integrity verification includes: calculating the SHA256 checksum of the local file after downloading the artifact, and comparing it with the checksum value returned by the central repository. Only when the two are consistent is the artifact allowed to enter the construction process, otherwise the construction is terminated and a verification failure prompt is output.

[0083] Specifically, when the dependency is determined to be a binary dependency, Aura prioritizes obtaining the corresponding binary artifact from the Central Registry. First, the system initiates a download request to the Central Registry based on the unique artifact identifier (e.g., SHA256 checksum or Artifact ID) in the metadata. Upon completion of the download, an integrity verification is immediately performed. The integrity verification process includes calculating the hash value of the locally downloaded artifact and comparing it with the signature value recorded in the metadata. If the hash verification is consistent and the signature passes, it is determined that the artifact has not been tampered with and the source is trustworthy. After verification, Aura registers the artifact in the local build context of the project, automatically updating the build script or link instruction, so that the binary file can be directly linked in the compilation stage without the need to recompile the source code. This mechanism not only significantly improves the build speed, but also reduces platform compatibility issues and potential security risks, as all binary artifacts are uniformly compiled and audited.

[0084] In contrast, when the dependency is determined to be a source code dependency, Aura processes it using a source-level integration approach. The system first pulls the corresponding source code package from the Central Registry or a specified code repository (such as Git or a private repository) based on the version information and source code package path in the dependency declaration. Subsequently, Aura decompresses the source code package into the build cache directory and executes the dependency build process according to the project's build specifications (such as Cargo.toml, Build.toml, or the project's own defined build script). During the build phase, Aura automatically identifies the language type, compiler version, and target platform of the dependency, and invokes the appropriate compilation command based on this information to complete the generation of executable files or library files from source code. After the build is complete, Aura links the products to the build product tree of the main project, ensuring consistency and reproducibility throughout the entire build process.

[0085] Through this mechanism, the Aura package manager achieves dynamic adaptation of the dependency integration approach, i.e., automatically selecting the appropriate integration path based on the characteristics of the dependency package (whether there is a secure and complete binary artifact). This ensures both efficient binary integration and the advantages of source code dependencies in terms of compatibility and transparency. The technical effect of this step is to significantly improve the automation level of the dependency resolution and build process, ensuring the security and verifiability of the build, and maintaining consistent build results in cross-platform and multi-language environments.

[0086] S105, if the Central Registry does not return a matching artifact, output error information and prompt the user to use local source code or other configuration sources for building.

[0087] Specifically, Aura will make a judgment based on the returned response status after issuing a dependency request. If the central warehouse returns "no matching item found" or the response times out, Aura will immediately record the abnormal state and generate a standardized error message. The error message contains three key parts: ① the name and version constraint of the missing dependency; ② the reason for the mismatch (e.g., version does not exist, platform is not compatible, is marked as deprecated, or security is unknown); ③ possible solution prompts. Subsequently, Aura will output this error message to the terminal and write it to the build log, making it easier for users to troubleshoot later.

[0088] Next, the system enters the user prompt phase. Aura will generate optional recovery solutions based on the context information in the dependency declaration (such as whether a local path, local mirror repository, Git repository link, or backup configuration source is defined) and prompt the user interactively. For example, when detecting fields such as path=".. / local-lib" or git="https: / / ...", the system will prompt the user whether they want to use these local or remote source code to build the dependency package; if there is a backup source in the configuration file (such as the [[source]] configuration item), Aura will also prompt whether to try to pull the dependency from the backup source. If the user confirms to use the local source code, Aura will automatically switch the dependency resolution path, perform source code pulling, compilation, and linking processes, and thus restore the build process.

[0089] If the user does not provide any alternative path, the system outputs a build termination prompt with detailed error reports. The report lists the impact range of the missing dependency (e.g., which upper-level modules depend on the package) and possible repair measures, such as adjusting version constraints, checking configuration file syntax, or contacting the repository administrator to update the artifact.

[0090] Through this mechanism, Aura realizes intelligent fault tolerance and fallback processing for dependency missing scenarios, ensuring the stability of the build system and avoiding the problem of "dependency loss leads to build failure" in traditional package managers. The technical effect of this process is:

[0091] On the one hand, it enhances the robustness and maintainability of the package manager, allowing the project to build successfully even in the face of network interruptions, version revocations, or repository migrations; on the other hand, it reduces the cost of manual intervention for developers through automated error prompts and local build guidance, improving the adaptive ability of dependency resolution and the overall robustness of the system.

[0092] Optionally, the artifacts that pass the integrity verification are stored in the local cache and indexed for subsequent build reuse.

[0093] Specifically, after verification, Aura writes the artifact into the local cache directory. The cache structure adopts a hierarchical management method, usually located in the ~ / .aura / cache / directory, and a unique storage path is constructed with the package name, version number, platform information, and hash value, for example:

[0094] ~ / .aura / cache / foo / 1.2.3 / linux-x86_64 / sha256-abcdef /

[0095] This hierarchical path structure can ensure data isolation and traceability when multiple versions coexist, multiple platforms are built, and cross-project sharing is performed. After storage is completed, the system simultaneously writes metadata information of the artifact into the local database (such as SQLite or a lightweight index file), including the package name, version, dependency type (source code or binary), integrity verification result, creation time, and last use time.

[0096] Aura preferentially queries the local cache index during subsequent build processes. When it is detected that the requested dependency package completely matches the identifier of the artifact in the cache, and the integrity state is “verified”, the system directly reuses the artifact without re-downloading from the central warehouse. If the artifact in the cache has expired (such as an updated version existing in the central warehouse), Aura triggers an automatic synchronization mechanism to re-request the latest metadata and perform verification to ensure the timeliness and security of the cache content.

[0097] In addition, to prevent cache expansion, the present application designs an intelligent cache eviction strategy. Aura automatically cleans up long-unused artifacts based on usage frequency and version timestamp, while retaining dependencies involved in recent multiple builds. This strategy ensures efficient utilization of cache space, and while ensuring reproducible builds, avoids storage waste.

[0098] Through the above design, Aura realizes trusted caching and indexed management of dependent artifacts. Its technical effects are reflected in two aspects:

[0099] On the one hand, the cache mechanism significantly reduces the time consumption caused by repeated downloading and compilation, making the build speed increase by about 40%–60%, and reducing network dependence; on the other hand, the cache index system combined with integrity verification guarantees a safe closed loop for the build process, so that each dependency reuse is based on a verifiable and traceable artifact source. This design effectively balances performance and security, enhancing the stability and maintainability of the package manager in large-scale engineering and continuous integration environments.

[0100] The binary dependency package management method in the above embodiment first parses the dependency declaration in the project configuration file; the dependency declaration defines the dependency package name and version constraint in a unified syntax format, without explicitly distinguishing between source code dependency or binary dependency; then, based on the dependency declaration, the central warehouse is communicated to obtain the metadata of the dependency package; the metadata includes available version information, dependency type information and security state information; then, the dependency decision is made according to the metadata; the dependency decision according to the metadata includes: when there is a binary artifact that meets the version constraint and is suitable for the current platform and the security state is safe, it is determined that the dependency package is a binary dependency; when the requested version does not exist and there is an updated version that meets the semantic version constraint, the user is prompted with the update information and a confirmation is requested; when the requested version is marked as high risk, the build is rejected and an error prompt containing risk details and repair suggestions is output; then, the corresponding acquisition and integration are performed based on the determined dependency type; the corresponding acquisition and integration based on the determined dependency type include: for binary dependency, the artifact is downloaded from the central warehouse and integrity verification is performed before it is linked to the build process; for source code dependency, the source code package is downloaded and compilation and linking are performed in the build stage; if the central warehouse does not return a matching artifact, error information is output and the user is prompted to use local source code or other configuration sources for building. In the build process, safe binary artifacts are automatically selected or the user is prompted to upgrade to a safe version, effectively avoiding the use of high-risk dependencies; according to the dependency type, downloading, integrity verification, cache management and build integration are automatically performed without manual intervention; at the same time, a fallback and user intervention mechanism is provided, so that even if the central warehouse does not provide a matching artifact, the build process can be controlled. This series of technical features comprehensively realizes dependency management automation, build security improvement and build process efficiency.

[0101] In order to more comprehensively show the present scheme, the present embodiment gives an optional way of the binary dependency package management method, as shown in Figure 2

[0102] S201, parsing the dependency declaration in the project configuration file.

[0103] The dependency declaration defines the dependency package name and version constraint in a unified syntax format, without explicitly distinguishing between source code dependency or binary dependency.

[0104] S202, sending a dependency metadata query request, the request including a dependency package name, version constraint and target platform triple information.

[0105] S203, receiving the JSON format response data returned by the central warehouse, the response data including version list, artifact type, platform compatibility information, security state and recommended version information.

[0106] The metadata includes available version information, dependency type information and security state information.​

[0107] S204, when there is a binary artifact that meets the version constraint and is applicable to the current platform, and the security status is safe, determining that the dependent package is a binary dependency.

[0108] S205, when the requested version does not exist but an updated version that meets the semantic version constraint exists, prompting the user for update information and requesting confirmation.

[0109] S206, when the requested version is marked as high risk, rejecting the build and outputting an error prompt containing risk details and repair suggestions.

[0110] Specifically, when the security status field in the metadata is marked as "high_risk", the build is automatically rejected, and an error prompt message with a security notification number, risk description, and recommended repair version is generated; when the security status is "clean" or "low_risk", the build is allowed to continue execution.

[0111] S207, when the dependent package returned by the central warehouse provides both binary artifacts and source code artifacts, the type of dependency to be used is determined according to a preset strategy or user interaction input, and the preset strategy includes a performance priority or a security priority strategy.

[0112] S208, for binary dependencies, the artifacts are downloaded from the central warehouse and integrity verification is performed, and then they are linked to the build process.

[0113] The integrity verification includes: calculating the SHA256 checksum of the local file after downloading the artifact, and comparing it with the checksum value returned by the central warehouse, and only when the two are consistent is the artifact allowed to enter the build process, otherwise the build is terminated and a verification failure prompt is output.

[0114] S209, for source code dependencies, the source code package is downloaded and compilation and linking are performed in the build stage.

[0115] S210, if the central warehouse does not return a matching artifact, output an error message and prompt the user to use local source code or other configuration sources for building.

[0116] S211, storing the artifacts that pass the integrity verification to the local cache and establishing an index for subsequent build reuse.

[0117] The specific processes of S201-S211 described above can be referred to the description of the method embodiments described above, which have similar implementation principles and technical effects, and will not be repeated here.

[0118] Based on the same inventive concept, the embodiment of the present application further provides a binary dependency package management device for implementing the binary dependency package management method. The device provides a solution to the problem similar to the implementation solution described in the above method, and therefore the specific limitations in one or more binary dependency package management device embodiments provided below can refer to the limitations of the binary dependency package management method described above, which will not be repeated here.

[0119] In one embodiment, as shown in Figure 3 a binary dependency package management device is provided, which comprises:

[0120] The declaration parsing module 30 is configured to parse the dependency declaration in the project configuration file; the dependency declaration defines the dependency package name and version constraint in a unified syntax format without explicitly distinguishing between source code dependency or binary dependency;

[0121] The data acquisition module 31 is configured to acquire the metadata of the dependency package based on the dependency declaration and communicate with the central repository; the metadata includes available version information, dependency type information and security state information;

[0122] The dependency decision module 32 is configured to make a dependency decision according to the metadata;

[0123] The dependency decision according to the metadata includes: when there is a binary artifact that meets the version constraint and is suitable for the current platform and the security state is safe, determining that the dependency package is a binary dependency; when the requested version does not exist but there is an updated version that meets the semantic version constraint, prompting the user with update information and requesting confirmation; when the requested version is marked as high risk, refusing to build and outputting an error prompt containing risk details and repair suggestions;

[0124] The acquisition and integration module 33 is configured to perform corresponding acquisition and integration based on the determined dependency type; performing corresponding acquisition and integration based on the determined dependency type includes: for binary dependency, downloading the artifact from the central repository and performing integrity verification before linking it to the build process; for source code dependency, downloading the source code package and performing compilation and linking in the build stage;

[0125] The information output module 34 is configured to output error information and prompt the user to use local source code or other configuration sources for building if the central repository does not return a matching artifact.

[0126] In another embodiment, the above Figure 3The data acquisition module 31 in the foregoing embodiment is specifically configured to: send a dependency metadata query request, the request containing a dependency package name, a version constraint, and a target platform triple information; and receive a JSON format response data returned by the central warehouse, the response data including a version list, a product type, platform compatibility information, a security status, and recommended version information.

[0127] In another embodiment, the foregoing Figure 3 The dependency decision module 32 in the foregoing embodiment is specifically configured to: when the security status field in the metadata is marked as "high_risk", automatically reject the build, and generate an error prompt information with a security announcement number, a risk description, and a recommended repair version; and when the security status is "clean" or "low_risk", allow the build to continue to execute.

[0128] In another embodiment, the foregoing Figure 3 The acquisition integration module 33 in the foregoing embodiment is specifically configured to: calculate a SHA256 checksum of a local file after downloading a product, and compare the checksum with a checksum value returned by the central warehouse, and only when the two are consistent, allow the product to enter a build process, otherwise terminate the build and output a checksum failure prompt.

[0129] In another embodiment, the foregoing Figure 3 The binary dependency package management apparatus in the foregoing embodiment is further specifically configured to: when the dependency package returned by the central warehouse simultaneously provides a binary product and a source code product, determine the dependency type to be adopted according to a preset strategy or user interactive input, the preset strategy including a performance priority or a security priority strategy.

[0130] In another embodiment, the foregoing Figure 3 The binary dependency package management apparatus in the foregoing embodiment is further specifically configured to: store the product that passes the integrity verification to a local cache and establish an index, for subsequent build reuse.

[0131] Embodiments of the present application also provide an electronic device. In some embodiments, as shown in Figure 4 The electronic device 700 includes an input unit 710, a memory 720, a processor 730, and an output unit 740. The memory 720 stores program instructions executable on the processor 730, and the processor 730 invokes the program instructions to perform the binary dependency package management method and / or technical solutions in the foregoing embodiments. The electronic device 700 can be a mobile terminal device such as a mobile phone or a computer.

[0132] In addition, the embodiments of the present application further provide a computer readable storage medium for storing a computer program for executing the management method of the binary dependency package. For example, the computer program instructions, when executed by a computer, can call or provide the method and / or technical solutions according to the present application through the operation of the computer. The program instructions for calling the method of the present application can be stored in a fixed or removable storage medium, and / or transmitted and / or stored in a storage medium running according to the program instructions through a data stream in a broadcast or other signal bearing medium.

[0133] Obviously, those skilled in the art should understand that the modules or steps of the present application described above can be realized by general computing devices, which can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be realized by program codes executable by computing devices, so that they can be stored in storage devices and executed by computing devices, or they can be respectively manufactured into integrated circuit modules, or multiple modules or steps among them can be manufactured into a single integrated circuit module to realize. Therefore, the present application is not limited to any specific combination of hardware and software.

[0134] The technical features of the above embodiments can be integrated in any manner. In order to make the description simple, all possible integrations of the technical features in the above embodiments are not described, however, as long as the integration of the technical features does not exist contradictions, it should be considered as the scope of the present application.

[0135] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for managing binary dependency packages, characterized in that, The method includes: Parse the dependency declarations in the project configuration file; the dependency declarations use a uniform syntax format to define the dependency package name and version constraints, without explicitly distinguishing between source code dependencies and binary dependencies; Based on the dependency declaration, communication is established with the central repository to obtain the metadata of the dependency packages; the metadata includes available version information, dependency type information, and security status information. Dependency decisions are made based on the aforementioned metadata; Dependency decisions are made based on the metadata, including: when a binary artifact that conforms to version constraints, is applicable to the current platform, and is in a secure state, determining that the dependency package is a binary dependency; when the requested version does not exist but an updated version that conforms to semantic version constraints exists, prompting the user with update information and requesting confirmation; when the requested version is marked as high risk, refusing to build and outputting an error message containing risk details and remediation suggestions. Based on the defined dependency type, perform the corresponding fetching and integration, including: for binary dependencies, download the artifact from the central repository, perform integrity verification, and then link it to the build process; for source code dependencies, download the source code package and perform compilation and linking during the build phase. If the central repository does not return a matching artifact, an error message will be output, prompting the user to build using local source code or other configuration sources.

2. The binary dependency package management method as described in claim 1, characterized in that, The process of communicating with the central repository based on the dependency declaration to obtain the metadata of the dependency package includes: Send a dependency metadata query request, the request including the dependency package name, version constraints and target platform triplet information; The system receives JSON-formatted response data from the central warehouse. This response data includes a version list, product type, platform compatibility information, security status, and recommended version information.

3. The binary dependency package management method as described in claim 1, characterized in that, Dependency decisions are made based on the metadata, including: When the security status field in the metadata is marked as "high_risk", the build is automatically rejected, and an error message with a security bulletin number, risk description and recommended fix version is generated. When the safety status is "clean" or "low_risk", the build is allowed to continue.

4. The binary dependency package management method as described in claim 1, characterized in that, The integrity verification includes: After downloading the artifact, calculate the SHA256 checksum of the local file and compare it with the checksum value returned by the central repository. Only if the two match will the artifact be allowed to enter the build process; otherwise, terminate the build and output a checksum failure message.

5. The binary dependency package management method as described in claim 1, characterized in that, The method further includes: When the dependency package returned by the central repository provides both binary artifacts and source code artifacts, the dependency type to be adopted is determined according to a preset strategy or user interaction input. The preset strategy includes a performance-first or security-first strategy.

6. The method for managing binary dependency packages as described in any one of claims 1-5, characterized in that, The method further includes: Artifacts that pass integrity verification are stored in a local cache and indexed for reuse in subsequent builds.

7. A binary dependency package management device, characterized in that, The device includes: The dependency declaration parsing module is used to parse dependency declarations in the project configuration file. The dependency declarations use a unified syntax format to define the dependency package name and version constraints, without explicitly distinguishing between source code dependencies and binary dependencies. The data acquisition module is used to communicate with the central repository based on the dependency declaration to obtain the metadata of the dependency package; the metadata includes available version information, dependency type information, and security status information; A dependency decision module is used to make dependency decisions based on the metadata; Dependency decisions are made based on the metadata, including: when a binary artifact that conforms to version constraints, is applicable to the current platform, and is in a secure state, determining that the dependency package is a binary dependency; when the requested version does not exist but an updated version that conforms to semantic version constraints exists, prompting the user with update information and requesting confirmation; when the requested version is marked as high risk, refusing to build and outputting an error message containing risk details and remediation suggestions. The acquisition and integration module is used to perform corresponding acquisition and integration based on the defined dependency types. This includes: for binary dependencies, downloading artifacts from the central repository, verifying their integrity, and then linking them to the build process; for source code dependencies, downloading the source code package and performing compilation and linking during the build phase. The information output module is used to output error messages and prompt the user to build using local source code or other configuration sources if the central warehouse does not return a matching artifact.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the binary dependency package management method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the binary dependency package management method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the binary dependency package management method according to any one of claims 1 to 6.

Images