Software package building method and apparatus, software package management method and apparatus, and related products

Abstract

The embodiments of the present application belong to the technical field of computers. Disclosed are a software package building method and apparatus, a software package management method and apparatus, and related products. In the software package building method, a first build script is modified after being acquired, and a second installation path in a second build script, which is obtained after the modification, is related to a plurality of build elements for a first software package. Therefore, the first software package can be installed into a path related to the plurality of build elements, rather than being installed into a fixed path only related to the name of the software package. Accordingly, for two software packages that share the same name but differ in a plurality of build elements, second installation paths of the two software packages are different, such that the two software packages can be installed together on the same operating system. Therefore, the embodiments of the present application can modify build scripts for software packages in formats such as rpm and deb, so as to improve the application flexibility of such software packages on a Linux operating system.

Description

Methods for building software packages, methods for managing software packages, devices and related products

[0001] This application claims priority to Chinese Patent Application No. 202411181175.7, filed on August 26, 2024, entitled "Method for constructing a software package, method for managing a software package, apparatus and related products", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a method for building software packages, a method for managing software packages, an apparatus, and related products. Background Technology

[0003] Currently, software packages running on Linux operating systems are typically in formats such as Red Hat Package Manager (rpm) or deb (Debian). These packages can be directly created using corresponding package creation tools. Taking rpm packages as an example, developers can first write a build script, which configures the information required for each stage of the package building process. Then, the rpmbuild tool is used to build the package according to the build script to obtain the rpm package. However, the installation path of a package built in this way is a fixed path that is only related to the package name. Thus, two different packages with the same name will be installed to the same path. To avoid conflicts, for rpm or deb packages, a Linux operating system only allows one package with the same name to be installed. In other words, different packages with the same name cannot coexist on the same Linux operating system, thus limiting the application of these packages on Linux. Summary of the Invention

[0004] This application provides a method for building software packages, a method for managing software packages, an apparatus, and related products, which can modify the build scripts of software packages in formats such as rpm and deb to improve the application flexibility of these software packages on the Linux operating system. The technical solution is as follows:

[0005] In a first aspect, a method for building a software package is provided, in which: a first build script for building a first software package is obtained, the first build script including a first installation path, the first installation path being used to indicate the installation location of an object file, the object file being a file compiled during the process of building the first software package; a second build script is determined based on the first build script, the second build script including a second installation path, the second installation path being used to indicate the installation location of the object file, and the second installation path being related to multiple build elements of the first software package; and the first software package is built based on the second build script, the first software package carrying the second installation path.

[0006] Since the second installation path and the first installation path are used to indicate the installation location of the same target file, and there will not be two different installation paths for the same target file in the same build script, in the process of determining the second build script based on the first build script, this application is equivalent to replacing the first installation path with the second installation path, so as to redirect the installation location of the target file from the first installation path to the second installation path.

[0007] Therefore, in this application, after obtaining the first build script, to avoid the first installation path in the first build script being a fixed path only related to the package name, the first build script is modified. The second installation path in the modified second build script is related to multiple build elements of the first package. Thus, the first package can be installed to a path related to multiple build elements, instead of a fixed path only related to the package name. Correspondingly, for two packages with the same name but different build elements, the second installation paths of these two packages will be different, allowing them to be installed together on the same operating system. Therefore, the method provided in this application can modify the build scripts of packages in formats such as rpm and deb to improve the application flexibility of these packages on the Linux operating system.

[0008] Based on the method provided in the first aspect, in one possible implementation, a build element is used to build a first software package. The first installation path is redirected to a second installation path via the element used to build the first software package.

[0009] Based on the method provided in the first aspect, in one possible implementation, the second installation path includes a build element identifier, which is calculated from multiple build elements of the first software package.

[0010] Since the construction element identifier is calculated from multiple construction elements, if any one of the construction elements changes, the final calculated construction element identifier will be different. Therefore, when any one of the construction elements changes, the final determined second installation path will be a different installation path.

[0011] Based on the method provided in the first aspect, in one possible implementation, the second installation path includes the first installation path and a first extended directory located above the first installation path, the first extended directory including the build element identifier.

[0012] In this scenario, simply adding a first extended directory containing the build element identifier above the first installation path will redirect the first installation path, which is easy to implement.

[0013] Based on the method provided in the first aspect, in one possible implementation, multiple build elements of the first software package include a version identifier of the first software package.

[0014] Since the second installation path is related to multiple build elements of the first software package, and these build elements include the version identifier of the first software package, in this application, after obtaining the first build script, the first build script is modified so that the second installation path in the modified second build script is related to the version identifier of the first software package. Accordingly, the first software package can then be installed to a path associated with the version identifier. Therefore, the software package built using this application can enable the installation of multiple software packages with the same name but different versions on the same operating system, thereby solving the multi-version compatibility problem.

[0015] On the one hand, multi-version compatibility issues can be resolved by specifying the installation path associated with the version identifier. This eliminates the need to package the dependency packages themselves inside the software package, thus avoiding the problems that occur when the dependency packages are directly packaged inside the software package in technologies such as Snap and Flatpak.

[0016] On the other hand, the method provided in this application only requires modification of the obtained first build script. Therefore, resources from existing package building technologies can be reused to obtain the first build script, such as resources from rpm or deb package building technologies. The first installation path in the first build script can then be redirected to a second installation path associated with a version identifier to solve multi-version compatibility issues. Unlike NIX technologies, this application does not require writing build scripts in a custom language to configure an independent installation path for each version of the package, thus reducing the learning curve.

[0017] Based on the method provided in the first aspect, in one possible implementation, the version identifier of the first software package includes the version number and release number of the first software package.

[0018] In this application, a combination of version number and serial number can be used as the version identifier. For any two software packages with the same name, if either the version number or the serial number is different, or if both are different, then the two software packages are considered to be different versions. Only if both the version number and the serial number are the same are the two software packages considered to be the same version.

[0019] Based on the method provided in the first aspect, in one possible implementation, the first installation path is independent of the version identifier of the first software package.

[0020] In this application, the first build script can be a build script obtained from resources in the RPM format package build technology, such as a spec file. As another example, the first build script can be a build script obtained from resources in the DEB format package build technology, such as control files and rule files. In these scenarios, the first installation path in the first build script is unrelated to the version identifier of the first package. The solution provided in this application allows the first build script to be modified to generate a first package that includes a second installation path. Since the second installation path is related to the version identifier of the first package, the multi-version compatibility problem can be solved.

[0021] Based on the method provided in the first aspect, in one possible implementation, the multiple build elements of the first software package include at least one of the following: the source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package.

[0022] In this scenario, if any of these building elements changes, the final determined second installation path will be a different installation path.

[0023] Based on the method provided in the first aspect, in one possible implementation, the first software package corresponds to at least one dependent package, and the at least one dependent package includes the first dependent package; the first software package contains built-in first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependent package, and the third installation path is related to multiple build elements of the first dependent package.

[0024] In this application, after the first software package is generated, if the dependent packages of the first software package are also installed in the installation path related to multiple build elements, the installation path of the dependent packages can be built into the first software package in order to accurately find the dependent packages when installing or running the first software package later.

[0025] Based on the method provided in the first aspect, in one possible implementation, the first software package contains a built-in Software Bill of Materials (SBOM) or a label for the SBOM, which is used to record the elements used in the construction process of the first software package.

[0026] The first software package constructed using this application contains a built-in Software Bill of Materials (SBOM) or a label for the SBOM, so that subsequent users can detect vulnerabilities in the first software package based on the SBOM or the label for the SBOM.

[0027] Based on the method provided in the first aspect, in one possible implementation, the process of obtaining the first build script for building the first software package is as follows: obtaining the source code package of the first software package from the software package source code repository, and determining the first build script based on the source code package; or, obtaining the software artifact of the first software package from the software artifact repository, and determining the first build script based on the software artifact; or, obtaining the already built second software package, and determining the first build script based on the second software package, wherein the second software package has the same name as the first software package.

[0028] The above three methods allow us to reuse resources from existing software package building technologies to obtain the first build script.

[0029] Based on the method provided in the first aspect, in one possible implementation, the first build script includes a first storage path of the target script, the target script being a script executed before or after the installation of the first software package, and the second build script includes a second storage path of the target script, the second storage path being related to the code in the target script.

[0030] In this application, in order to further improve the application flexibility of the pre-installation and post-installation execution scripts, the default script storage path of these pre-installation and post-installation execution scripts in the first build script can be redirected.

[0031] Secondly, a method for managing software packages is provided, in which a first software package is obtained, the first software package carrying a second installation path, the first software package being built based on a second build script, the second build script being determined based on the first build script, the first build script including a first installation path, both the second installation path and the first installation path being used to indicate the installation location of object files, the object files being files compiled during the process of building the first software package, and the second installation path being related to multiple build elements of the first software package; the first software package is installed and run according to the second installation path.

[0032] The first software package carries a second installation path, allowing subsequent user installations of the first software package according to this path. Since the second installation path is associated with multiple build elements of the first software package, the first software package can be installed into a path related to multiple build elements, rather than a fixed path associated only with the package name. Correspondingly, for two software packages with the same name but different build elements, their second installation paths will be different, allowing them to be installed together on the same operating system. Therefore, the method provided in this application can modify the build scripts for software packages in formats such as rpm and deb, improving the flexibility of these packages on the Linux operating system.

[0033] Based on the method provided in the second aspect, in one possible implementation, the process of installing and running the first software package according to the second installation path is as follows: the first software package is added to the operating system according to the second installation path, and a user environment is created on the operating system; a soft link is established between the first path in the user environment and the second installation path; the first software package is run in the user environment through the first path.

[0034] When multiple user environments are created on an operating system, users in any user environment can run the first software package in their respective user environment using the method described above. For example, if user environment 1 and user environment 2 are created on the operating system, and a user in user environment 1 first installs and runs the first software package using the method described above, when a user in user environment 2 installs and runs the first software package again using the same method, since the first software package was added to the operating system via the second installation path, adding the first software package to the operating system will detect that it has already been added. Therefore, it is not necessary to add it again; only a symbolic link needs to be created between the first path in user environment 2 and the second installation path. This allows the first software package to be added only once on the same operating system, and then run in different user environments via the corresponding first path. This avoids the need to repeatedly add the first software package to the operating system, thus saving operating system storage space.

[0035] Based on the method provided in the second aspect, in one possible implementation, the user environment is configured with a file directory structure based on the File System Hierarchy Standard (FHS), and the first path is a path under the file directory structure.

[0036] Since users run the first software package through a first path, which is a path based on the FHS file directory structure, this application, even with modifications to the package's installation path, can still run the first software package through a path based on the FHS file directory structure, thus achieving compatibility with FHS. This solves the current incompatibility problem between Nix technology and FHS.

[0037] Based on the method provided in the second aspect, in one possible implementation, the first software package corresponds to at least one dependency package, the at least one dependency package includes the first dependency package, the first software package contains built-in first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependency package, and the third installation path is related to multiple build elements of the first dependency package.

[0038] In this scenario, in this method, if the first dependency package is updated, the installation path of the updated first dependency package is obtained to get the fourth installation path; the third installation path carried by the first dependency configuration information is updated to the fourth installation path to get the updated first software package; or, the fourth installation path is updated to the second dependency configuration information, which is the dependency configuration information set in the user environment running the first software package.

[0039] In scenarios where the dependency packages of the first software package are also built using the method provided in this application, if the dependency packages are updated, since some of the multiple build elements of the dependency packages also change when the dependency packages are updated, the installation path of the dependency packages will also change. In this case, only the installation path of the dependency packages needs to be updated for the first software package, without recompiling the entire first software package, thus improving the efficiency of software package updates.

[0040] Based on the method provided in the second aspect, in one possible implementation, the first software package corresponds to at least one dependent package, the at least one dependent package includes a second dependent package, the source code information in the first software package includes the specified installation path of the second dependent package, and the source code information is compiled from the source code package of the first software package.

[0041] In this scenario, the method mounts the specified installation path to a second path in the user environment running the first software package. The second path is used to store the second dependency configuration information, which records the installation path of the second dependency package. During the execution of the first software package, the installation path of the second dependency package is found in the second dependency configuration information through the second path.

[0042] If the installation path of a dependency package is specified in the source code of the first software package, meaning the installation path is hardcoded in the source code, the loader on the operating system will directly search for the dependency package in that specified installation path when the first software package is run. However, in this application, if the actual installation path of the dependency package is also related to multiple build elements of the dependency package, such as version identifiers, then the dependency package may not be found or may be found incorrectly in that specified installation path. For example, if the dependency package is not installed in the specified installation path, then the dependency package will not be found when running the first software package. Or, for example, if the first software package requires version 1 of a dependency package, but the version of the dependency package installed in the specified installation path is version 2, then the dependency package will be found incorrectly when running the first software package.

[0043] By using the above method, the installation path of a specific dependency package specified in the source code package of the first software package is mounted into the user environment. Thus, when the first software package is run in the user environment, the loader will not look for the dependency package in the specified installation path, but will instead look for the dependency package's installation path within the user environment, thereby resolving the issue of not being able to find the dependency package from the specified installation path.

[0044] Based on the method provided in the second aspect, in one possible implementation, the first software package contains a built-in Software Bill of Materials (SBOM) or a label for the SBOM, which is used to record the elements used in the construction process of the first software package.

[0045] In this scenario, the method involves obtaining the SBOM or its tag from the first software package; and determining the security vulnerability of the first software package based on the SBOM or its tag.

[0046] Because the first software package contains a built-in SBOM or SBOM tag, the user client can perceive the security vulnerabilities of the first software package based on the SBOM or SBOM tag after running the first software package.

[0047] Thirdly, an apparatus for building a software package is provided, the apparatus having the functionality to implement the method behavior of building a software package as described in the first aspect. The apparatus for building a software package includes at least one module for implementing the method for building a software package provided in the first aspect.

[0048] Fourthly, an apparatus for managing software packages is provided, the apparatus having the functionality to implement the method behavior of managing software packages as described in the second aspect above. The apparatus for managing software packages includes at least one module for implementing the method for managing software packages provided in the second aspect above.

[0049] Fifthly, a computing device cluster is provided, including at least one computing device, each computing device including a processor and memory;

[0050] The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the method of building a software package as described in the first aspect, or the method of managing a software package as described in the second aspect.

[0051] In a sixth aspect, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the method for building a software package as described in the first aspect, or the method for managing a software package as described in the second aspect.

[0052] In a seventh aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the method for building a software package as described in the first aspect, or the method for managing a software package as described in the second aspect.

[0053] The technical effects achieved by the technical means corresponding to the second to seventh aspects mentioned above are similar to those achieved by the technical means corresponding to the first or second aspects, and will not be repeated here. Attached Figure Description

[0054] Figure 1 is a schematic diagram of the architecture of a system for building software packages provided in an embodiment of this application;

[0055] Figure 2 is a schematic diagram of the architecture of another system for building software packages provided in an embodiment of this application;

[0056] Figure 3 is a schematic diagram of the architecture of another system for building software packages provided in an embodiment of this application;

[0057] Figure 4 is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0058] Figure 5 is a flowchart of a method for building a software package according to an embodiment of this application;

[0059] Figure 6 is a schematic diagram of a software package installed on an operating system;

[0060] Figure 7 is a schematic diagram of a scenario in which hash values ​​are calculated for multiple building elements of a first software package according to an embodiment of this application;

[0061] Figure 8 is a schematic diagram of a scenario in which a second construction script is obtained by modifying a first construction script according to an embodiment of this application;

[0062] Figure 9 is a schematic diagram of an SBOM provided in an embodiment of this application;

[0063] Figure 10 is a flowchart of a method for managing software packages provided in an embodiment of this application;

[0064] Figure 11 is a schematic diagram of a multi-user environment provided in an embodiment of this application;

[0065] Figure 12 is a schematic diagram of the overall process of building and installing software packages according to an embodiment of this application.

[0066] Figure 13 is a schematic diagram of a device for building software packages provided in an embodiment of this application;

[0067] Figure 14 is a schematic diagram of the structure of a management software package device provided in an embodiment of this application. Detailed Implementation

[0068] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0069] Before providing a detailed explanation of the embodiments of this application, the technical terms and application scenarios involved in the embodiments of this application will be explained first.

[0070] Software package: A software package can be understood as a component with independent functions and responsibilities, such as a program, a library, or a system tool. Multiple software packages can be installed on a Linux operating system.

[0071] Dependency packages: Other software packages that a software package depends on at runtime, such as libraries that the software package depends on at runtime. It should be noted that, in this embodiment, dependency packages refer to other software packages that the software package directly depends on at runtime. For example, if software package A directly depends on software package B at runtime, then software package B is included in the dependency packages of software package A.

[0072] Build script: A script file used to configure the information required for each stage of the software package building process.

[0073] Currently, the primary software package formats installed on Linux operating systems are rpm and deb. For example, openEuler (a Linux operating system for digital infrastructure) uses rpm packages. For rpm or deb packages, the installation path on a Linux operating system is pre-defined, such as ` / usr / bin / xxx`, where `xxx` is the name of a file within the package. Therefore, for two different packages with the same name, the `xxx` file from both packages will be installed to this path. To avoid conflicts, a Linux operating system only allows one package with the same name to be installed for rpm or deb packages. In other words, different packages with the same name cannot coexist on the same Linux operating system, which severely limits the types of packages that can be installed on a Linux operating system.

[0074] The above explanation uses the Linux operating system as an example. The same problem exists on other Unix-like operating systems. In this application, the Unix-like operating system is simply referred to as an operating system; in other words, the operating system in this application refers to Unix-like operating systems such as Linux.

[0075] Based on this, embodiments of this application provide a method for building software packages. In this method, after obtaining a first build script, to avoid the first installation path in the first build script being a fixed path only related to the package name, the first build script is modified. The second installation path in the modified second build script is related to multiple build elements of the first software package. Thus, the first software package can be installed to a path related to multiple build elements, instead of a fixed path only related to the package name. Correspondingly, for two software packages with the same name but different build elements, the second installation paths of these two software packages will be different, thereby enabling them to be installed together on the same operating system. Therefore, the method provided by embodiments of this application can modify the build scripts of software packages in formats such as rpm and deb to improve the application flexibility of such software packages on the Linux operating system.

[0076] The implementation environment involved in the application embodiments is described below.

[0077] The following is a general description of the process of building a software package based on a build script. The process typically includes the following steps.

[0078] (1) Prepare the build environment. This typically includes: preparing the operating system, installing the package build tools on the operating system, and then creating a directory tree within the operating system. The directories in this tree are used to store files used or generated during the subsequent package build process. The package build tools are used to build the package according to the build script.

[0079] Taking building an RPM software package as an example, the package build tool is rpmbuild. The example implementation of preparing the build environment is as follows: Prepare an operating system. If rpmbuild is not installed on the operating system, install it and create five directories under the / rpmbuild directory. These five directories are: SOURCE, BUILD, SPEC, SRPM, and RPM. The SOURCE directory stores the source code packages and all patch packages used in packaging (i.e., building the software package). The source code packages are, for example, tar archives. The BUILD directory stores the files after unpacking the source code packages and patch packages from the SOURCE directory. The SPEC directory stores the spec files, which are the build scripts used when building the RPM software package. The SRPM directory stores the source files in RPM format generated during packaging. The RPM directory stores the binary files in RPM format generated during packaging.

[0080] (2) Use a package build tool to complete the package build process and obtain a built package.

[0081] Taking building an RPM software package as an example, the rpmbuild tool's operations typically include: creating a temporary root directory, reading the source package and patch package from the SOURCE directory, decompressing the source package and patch package and storing them in the BUILD directory, and completing the compilation process of the source package and patch package in the BUILD directory according to the compilation operations indicated by the build script. After compilation, the compiled files are installed to the temporary root directory according to the installation path indicated by the build script. Then, the files in the temporary root directory are collected according to the file information indicated by the build script, and the collected files are packaged into a software package. Finally, the temporary root directory is deleted, and the software package building process ends.

[0082] Accordingly, in order to implement the above operations of the rpmbuild tool, the operations for each stage need to be specified in the spec file. A typical spec file includes the following sections: a section starting with %prep, a section starting with %build, a section starting with %install, and a section starting with %files.

[0083] The information following %prep indicates the operations in the preprocessing stage, such as the storage location of the decompressed source code package and patch package; the information following %build indicates the operations in the compilation stage, such as the storage location of the files in the compilation stage; the information following install% indicates the storage location of the files in the installation stage; and the information following files% indicates which files to collect and package into the software package.

[0084] In addition to the paragraphs mentioned above, the spec file may also include, for example, paragraphs starting with %changelog, %pre, and %post. The information following %changelog is used to record the modification log of the corresponding package. The information following %pre indicates the scripts that need to be executed before installing the corresponding package. The information following %post indicates the scripts that need to be executed after installing the corresponding package.

[0085] It should be noted that the above process of building the software package is illustrated using the rpmbuild tool as an example. Optionally, in this embodiment, other software package building tools can also be used to build the software package, which will not be illustrated here.

[0086] Figure 1 is a schematic diagram of the architecture of a system for building software packages provided in an embodiment of this application. As shown in Figure 1, the system includes a build subsystem 1, a software repository management subsystem 2, and a package management subsystem 3.

[0087] The build subsystem 1 is used to build a new format software package using the method provided in the embodiments of this application, and put the built software package into the software repository management subsystem 2. That is, the software repository management subsystem 2 is used to store each built software package. The package management subsystem 3 is used to interact with the software repository management subsystem 2 and provide users with a package download entry. In other words, users can download the software packages in the software repository management subsystem 2 to the operating system through the package management subsystem 3 to install and run the software packages on the operating system. The package management subsystem 3 is also used to manage the software packages installed on the operating system, such as package updates or package vulnerability detection.

[0088] The build subsystem 1 can reuse resources from existing software package build technologies, such as those from rpm or deb software package build technologies, to obtain a first build script. It then modifies the first build script to obtain a second build script and uses the second build script to generate a software package in a new format. This new format software package can be installed into paths associated with multiple build elements of the software package. The resources from existing software package build technologies include, for example, existing source code packages, build scripts, or binary software packages. Further details are provided in the embodiment shown in Figure 2.

[0089] The functions of each subsystem shown in Figure 1 are explained below.

[0090] Figure 2 is a schematic diagram of the architecture of another system for building software packages provided in an embodiment of this application. As shown in Figure 2, the build subsystem 1 includes an existing software package ecosystem module 11, a package addition tool module 12, a software specification module 13, a repack module 14, and a build module 15.

[0091] It should be noted that Figure 2 is an example structure of building subsystem 1. The embodiments of this application do not limit the internal modules of building subsystem 1. When applying the embodiments of this application, building subsystem 1 may include more or fewer modules, which will not be illustrated here.

[0092] As shown in Figure 2, the existing software package ecosystem module 11 includes a software package source code repository, a software package artifact repository, and a binary software package repository. The software package source code repository stores multiple source code packages, each containing the source code required to build a software package. The software package artifact repository stores multiple software artifacts, each containing a source code package and a build script. The binary software package repository stores multiple pre-built binary software packages. In this embodiment, the pre-built software packages are binary software packages; therefore, the repository storing pre-built software packages is called the binary software package repository.

[0093] It should be noted that different repositories in the existing software package ecosystem module 11 are used to provide different resources to determine the first build script. In this embodiment, the existing software package ecosystem module 11 may include some or all of the software package source code repository, software package artifact repository, and binary software package repository. Optionally, the existing software package ecosystem module 11 may also include other types of repositories to provide more resources to determine the first build script, which will not be illustrated here.

[0094] The package addition tool module 12 is used to scan source code packages to obtain various package description information of the software package to be built, such as obtaining the dependent packages of the software package and running the dependent packages, thereby generating a build script, and putting the generated build script and the source code package together as a software package artifact into the software package artifact repository.

[0095] The type of build script generated by the package addition tool module 12 is related to the functionality of the package addition tool itself. For example, when the package addition tool is used in a technology for building RPM format software packages, the generated build script is a first type of build script, which is typically a spec file. Alternatively, when the package addition tool is used in a technology for building DEB format software packages, the generated build script is a second type of build script, which is typically a control file and rules files.

[0096] The Software Specification Module 13 is used to convert various types of build scripts in the software package artifact repository into software specifications, such as those in YAML format. This serves two purposes: firstly, it facilitates subsequent operations in the build script conversion submodule; secondly, due to the editability of the software specifications, developers can customize certain information within the specifications as needed.

[0097] Taking a software specification in YAML format as an example, this specification typically records the software package name, build requirements, language, and define flags. This application does not limit the content of the software specification.

[0098] Module 15 includes a build script transformation submodule, a prefix calculation submodule, a build relocatable submodule, a dependency absolute pathing submodule, and an SBOM generation submodule.

[0099] It should be noted that Figure 2 is an example structure of the building module 15. The embodiments of this application do not limit the internal modules of the building module 15. When applying the embodiments of this application, the building module 15 may include more or fewer modules, which will not be illustrated here.

[0100] The build script conversion submodule is used to convert the software manual obtained by the software manual module 13 into a build script of a specified type, and use the build script of the specified type as the first build script. Then, through the subsequent prefix calculation submodule and build redirection submodule, the first build script is transformed into a second build script, so as to generate a first software package in a new format through the second build script.

[0101] The specified type is related to the build tool used to build the first package. For example, if the build tool is rpmbuild, the specified type of build script is a spec file.

[0102] The prefix calculation submodule performs calculations, such as hash algorithms, on multiple build elements of the first software package to be built, and uses the calculated results as build element identifiers for the multiple build elements of the first software package. The build redirection submodule redirects the first installation path used in the installation phase of the first build script according to the build element identifiers to obtain a second installation path, thereby transforming the first build script into a second build script.

[0103] The dependency path absolute submodule is used to embed the installation paths of the dependency packages of the first software package into the first software package. Thus, if a dependency package of the first software package is also a software package built using the embodiments of this application, the installation path of that dependency package is also a path related to multiple build elements of that dependency package. This allows the correct dependency package to be found through the installation paths embedded in the first software package during subsequent installation and operation.

[0104] The phrase "incorporating the installation paths of the dependent packages of the first software package into the first software package" can be understood as: incorporating the installation paths of all or part of the dependent packages of the first software package into the first software package. This application does not limit this aspect.

[0105] The SBOM generation submodule is used during the construction of the first software package to generate a software bill of materials (SBOM) based on the elements used in the build process, and embeds the SBOM or its tags into the first software package. Subsequently, after running the first software package, the SBOM can be used to analyze for security vulnerabilities.

[0106] Additionally, as shown in Figure 2, the build subsystem 1 also includes a repackaging module 14. The repackaging module 14 is used to repackage the already built software packages in the binary software repository. During the repackaging process, a first build script is generated, and then the prefix calculation submodule, build redirection submodule, dependency absolute pathing submodule, and SBOM generation submodule in the build module 15 are called to build the first software package provided in this embodiment. Detailed implementation will be described in the embodiment shown in Figure 5 later.

[0107] The build subsystem 1 shown in Figure 2 can reuse resources from existing software package build technologies, such as those from rpm or deb software package build technologies, to obtain a first build script. Then, the first build script is modified by the prefix calculation submodule and build redirection module in the build module 15 to obtain a second build script, and a first software package in a new format is generated based on the second build script.

[0108] The implementation method of reusing resources in existing software package building technologies to obtain the first build script can be referred to in the relevant embodiments in Figure 5, which will not be elaborated here.

[0109] In this embodiment of the application, the first software package obtained by the build module 15 includes a redirected second installation path. The second installation path is related to multiple build elements of the first software package. Therefore, if there are other software packages with the same name as the first software package but different build elements, the other software packages have other installation paths, thereby enabling multiple software packages with the same name to be installed on the same operating system.

[0110] Furthermore, since the first software package includes a second installation path related to multiple build elements, and the build process of the first software package differs from that of rpm and deb format software packages, to distinguish the format of the first software package provided in this application embodiment from the commonly used rpm and deb formats on current operating systems, the format of the first software package provided in this application embodiment can be referred to as the target format. In other words, through the build scheme provided in this application embodiment, a new target format software package can be built. For example, the target format can be labeled as epkg.

[0111] After building the first software package, the build module 15 stores it in the software repository management subsystem 2. As shown in Figure 2, the software repository management subsystem, for example, stores two software packages with the same name but different build elements, labeled as epkg package V1 and epkg package V2, respectively. The second installation path included in epkg package V1 is different from the second installation path included in epkg package V2, thus enabling the simultaneous installation of epkg package V1 and epkg package V2 on the same operating system.

[0112] Additionally, as shown in Figure 2, the package management subsystem 3 typically includes an environment management module, a transparent container module, a vulnerability awareness module, and a partial update module. These four modules are used to manage the first software package when it is installed or run on the operating system.

[0113] It should be noted that Figure 2 is an example structure of the package management subsystem 3. The internal modules of the package management subsystem 3 are not limited in this application embodiment. When applying this application embodiment, the package management subsystem 3 may include more or fewer modules, which will not be illustrated here.

[0114] The environment management module controls how users in each user environment install the first software package when multiple user environments are running on the operating system. This ensures that the first software package is added only once on the same operating system and can then run in different user environments. Detailed implementation will be explained in the embodiment shown in Figure 10.

[0115] The transparent container module is used to mount the installation path of a specific dependency package specified in the source code package of the first software package to the user environment during the execution of the first software package. Thus, when the first software package is run in the user environment, the loader will not look for the dependency package in the specified installation path, but will look for the installation path of the dependency package in the user environment, thereby resolving the corner case at runtime. Detailed implementation will be explained in the embodiment shown in Figure 10 below.

[0116] The partial update module is used in scenarios where the dependency packages of the first software package are also built using the method provided in the embodiments of this application. If the dependency packages are updated, since some of the multiple build elements of the dependency packages also change when the dependency packages are updated, the installation path of the dependency packages will also change. In this case, only the installation path of the dependency packages needs to be updated for the first software package, without recompiling the entire first software package, thus improving the efficiency of software package updates. Detailed implementation methods will be described in the embodiments shown in Figure 10 below.

[0117] The vulnerability awareness module is used to detect security vulnerabilities in the first software package and report these vulnerabilities to the operations and maintenance system to remind operations and maintenance personnel to fix them. For example, the vulnerability awareness module can obtain the SBOM or its tag from the first software package, identify basic information about the first software package using the SBOM, and then send this information to the vulnerability management platform. The vulnerability management platform then determines the security vulnerabilities in the first software package based on this information and returns the identified vulnerabilities to the vulnerability awareness module.

[0118] In addition, the package management subsystem 3 may also include a file deduplication module, a garbage collection module, an environment reproduction module, and a package AI module (these modules are not shown in Figure 2). The functions of these modules are not described in detail in this embodiment.

[0119] It should be noted that the function of any subsystem, module or submodule in the system shown in Figures 1 and 2 can be implemented by pure software or pure hardware. Optionally, it can also be implemented by a combination of software and hardware. This application embodiment does not limit this.

[0120] Figure 3 is a schematic diagram of the architecture of another system for building software packages provided in an embodiment of this application. As shown in Figure 3, the system includes a development end and a user end. The development end includes at least one computer device for implementing the functions of the build subsystem 1 shown in Figures 1 and 2. The user end includes at least one computer device for implementing the functions of the package management subsystem 3 shown in Figures 1 and 2.

[0121] The development side is used to build software packages using the methods provided in this application embodiment, and add the built software packages to the software repository management subsystem 2. The user side is used to obtain software packages from the software repository management subsystem 2, install and run the software packages on the operating system, and manage the software packages running on the operating system.

[0122] The following are examples of hardware involved in the embodiments of this application.

[0123] Figure 4 is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device can, for example, be the development terminal or user terminal shown in Figure 3. As shown in Figure 4, the computer device includes at least one processor 401, a communication bus 402, a memory 403, and at least one communication interface 404.

[0124] The processor 401 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0125] The communication bus 402 may include a path for transmitting information between the aforementioned components.

[0126] The memory 403 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or it may be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), a magnetic disk or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. The memory 403 may exist independently and be connected to the processor 401 via a communication bus 402. The memory 403 may also be integrated with the processor 401.

[0127] The memory 403 stores program code for executing the scheme of this application, and its execution is controlled by the processor 401. The processor 401 executes the program code stored in the memory 403. The program code may include one or more software modules, which are used to implement the method for building software packages or the method for managing software packages provided in the embodiments of this application.

[0128] Communication interface 404 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0129] In a specific implementation, as one embodiment, the computer device may include multiple processors, such as processor 401 and processor 405 shown in FIG. 4. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0130] In a specific implementation, as one embodiment, the computer device may further include an output device 406 and an input device 407. The output device 406 communicates with the processor 401 and can display information in various ways. For example, the output device 406 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 407 communicates with the processor 401 and can receive user input in various ways. For example, the input device 407 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0131] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld computer (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0132] The method for building software packages provided in the embodiments of this application will be explained below.

[0133] Figure 5 is a flowchart of a method for building a software package according to an embodiment of this application. This method is exemplarily applied to the build subsystem in the development terminal shown in Figure 3. As shown in Figure 5, the method for building the software package includes the following steps.

[0134] Step 501: Obtain the first build script for building the first software package. The first build script includes a first installation path, which indicates the installation location of the target files, which are files compiled during the process of building the first software package.

[0135] As described above, building a software package requires first compiling source code packages and patch packages, and then installing the compiled files to the installation path specified in the build script. Therefore, the target file in step 501 can be any file compiled during the software package building process. For example, the target file can be a file compiled from the source code package, or a file compiled from the patch package, etc.

[0136] The first build script includes not only the first installation path corresponding to the target file, but also the first installation paths corresponding to other compiled files. In other words, the first build script includes first installation paths corresponding to multiple files, each indicating its installation location. These multiple files are compiled during the process of building the first software package.

[0137] For example, the first build script includes 10 first installation paths corresponding to 10 files, all of which are files compiled during the process of building the first software package.

[0138] As shown in Figure 2, resources from existing software package building technologies can be reused to obtain the first build script. As shown in Figure 2, the existing software package ecosystem module 11 includes three types of repositories. Therefore, in this embodiment, reusing resources from existing software package building technologies to obtain the first build script can be achieved through the following three methods.

[0139] The first implementation method is to obtain the source code package of the first software package from the software package source code repository, and determine the first build script based on the source code package.

[0140] For example, as shown in Figure 2, the package addition tool module retrieves the source code package of the first software package to be built from the software package source code repository. It then uses the package addition tool to obtain a build script of a certain type, such as a spec file. This build script and the source code package are then placed into the software package artifact repository as the first software package artifact. The software manual module retrieves the build script from the software package artifact repository and converts it into a software manual, such as a YAML format manual. Developers customize certain information in the software manual to obtain an updated manual. Finally, the build script conversion submodule converts the updated software manual back into the first build script.

[0141] The second implementation method is to obtain the software artifact of the first software package from the software artifact repository and determine the first build script based on the software artifact.

[0142] For example, as shown in Figure 2, if the software artifact repository already contains the software artifact of the first software package to be built, the software specification module can directly obtain the software artifact of the first software package from the software package artifact repository. This software artifact includes the source code package and the build script. Then, the build script is converted into a software specification. Developers customize certain information in the software specification to obtain an updated software specification. The build script conversion submodule converts the updated software specification into the first build script.

[0143] In both of the above implementations, the build scripts in the software artifact repository are converted into software specifications, and then the first build script is obtained through the software specifications. Optionally, in this embodiment, the build scripts in the software artifact repository may not be converted into software specifications, but the build scripts in the software artifact may be directly used as the first build script.

[0144] The third implementation method is to obtain the already built second software package and determine the first build script based on the second software package.

[0145] For example, as shown in Figure 2, if a second software package already exists in the binary software package repository, and the second software package has the same name as the first software package, the repackaging module can analyze the second software package, generate the build script corresponding to the second software package, and obtain the first build script.

[0146] After obtaining the first build script through any of the above implementation methods, the prefix calculation submodule, build redirection module, dependency absolute pathing submodule, and SBOM generation submodule in build module 15 can be called to transform the first build script into a second build script, and then the first software package can be generated based on the transformed second build script. Detailed implementation methods can be found in subsequent steps 502 and 503.

[0147] It should be noted that the three implementation methods described above are used to illustrate how to obtain the first build script. In the embodiments of this application, the first build script can be a build script obtained through any existing software package build resource, and this embodiment of the application does not limit this.

[0148] Step 502: Determine a second build script based on the first build script. The second build script includes a second installation path, which indicates the installation location of the target file and is associated with multiple build elements of the first software package.

[0149] Since the second installation path and the first installation path are used to indicate the installation location of the same target file, and there will not be two different installation paths for the same target file in the same build script, the process of determining the second build script based on the first build script is equivalent to replacing the first installation path with the second installation path, so as to redirect the installation location of the target file from the first installation path to the second installation path.

[0150] As can be seen from step 501, the first build script may include a first installation path corresponding to multiple compiled files, and the target file is one of these multiple compiled files. In this scenario, for the other files in the multiple compiled files besides the target file, the first installation path corresponding to the other files can be replaced with a second installation path as per step 502, so that the installation location of the other files is also redirected from the first installation path to the second installation path.

[0151] For example, suppose the first build script includes 10 first installation paths corresponding to 10 files, and these 10 files are all compiled during the process of building the first software package. The second build script obtained through step 502 includes second installation paths corresponding to these 10 files.

[0152] Here, the build elements are the elements required to build the first software package. For example, the source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the operating system applicable to the first software package, and the first build script, etc. It should be noted that in step 502, multiple build elements refer to multiple build elements used to determine the second installation path. These multiple build elements can be some or all of the elements used to build the first software package, and the multiple build elements in subsequent embodiments can refer to this explanation.

[0153] As discussed above, for software packages in RPM or DEB formats, different packages with the same name cannot coexist on the same operating system. Therefore, these packages suffer from version compatibility issues. Version compatibility means that if two software packages have the same name but different versions, only one of them can be installed on the same operating system.

[0154] Figure 6 illustrates the installation of RPM or DEB format software packages on an operating system. As shown in Figure 6, if package B depends on version 1.1 of package D, and package C depends on version 1.2 of package D, assuming these packages are both in RPM or DEB format, because versions 1.1 and 1.2 of package D cannot be installed on the same operating system, package B and package C also cannot be installed on the same operating system. However, if both package B and package C depend on version 1.1 of package D, then package B and package C can be installed on the same operating system. Alternatively, if both package B and package C depend on version 1.2 of package D, then package B and package C can also be installed on the same operating system.

[0155] In some scenarios, the following two techniques can be used to solve the multi-version compatibility issues of software packages in formats such as rpm or deb.

[0156] In some technologies, such as Snap and Flatpak, the dependencies of a software package are packaged inside the package for installation, thereby solving the problem of multi-version compatibility.

[0157] However, this technique results in software packages that are bulky and, if two different packages contain the same dependency, this dependency is installed twice during the installation of both packages, leading to redundancy on the operating system. Furthermore, if the dependency has a security vulnerability, such as a common vulnerabilities and exposures (CVE) issue, both packages need to be rebuilt to update them. In contrast, with packages in RPM or DEB formats, if a dependency is updated, only the dependency needs to be updated because the package and its dependencies are installed independently. This makes techniques like Snap and Flatpak incompatible with RPM or DEB technologies.

[0158] In other technologies, such as NIX technology, a separate installation path is set for each software package installed on the operating system. For example, in Figure 6, two installation paths are set for software package D version 1.1 and software package D version 1.2 respectively. In this way, software package D version 1.1 and version 1.2 can be installed on the operating system at the same time, and thus software package B and software package C can be installed at the same time to solve the multi-version compatibility problem.

[0159] However, this technology requires writing build scripts in a custom language before building the software package; this custom language can be called a domain-specific language (DSL). Because mastering a custom language has a high barrier to entry, it increases the learning cost for developers.

[0160] Based on this, in step 502, the second installation path is associated with multiple build elements of the first software package, and these multiple build elements include the version identifier of the first software package. Thus, in this embodiment, after obtaining the first build script, the first build script is modified, and the second installation path in the modified second build script is associated with the version identifier of the first software package. Accordingly, the first software package can then be installed into a path associated with the version identifier. Therefore, the software package built using this embodiment can enable the installation of multiple software packages with the same name but different versions on the same operating system, thereby solving the multi-version compatibility problem.

[0161] On the one hand, multi-version compatibility issues can be resolved by specifying the installation path associated with the version identifier. This eliminates the need to package the dependency packages themselves inside the software package, thus avoiding the problems that occur when the dependency packages are directly packaged inside the software package in technologies such as Snap and Flatpak.

[0162] On the other hand, the method provided in this application only requires modification of the obtained first build script. Therefore, resources from existing software package building technologies can be reused to obtain the first build script, such as resources from rpm or deb software package building technologies. The first installation path in the first build script can then be redirected to a second installation path associated with a version identifier to solve the multi-version compatibility problem. Unlike NIX technologies, this application does not require writing build scripts in a custom language to configure an independent installation path for each version of the software package, thus reducing the learning curve.

[0163] The version identifier is used to uniquely identify the version of a software package. In this embodiment, for any two software packages with the same name, if any information in these two software packages changes, such as changes in source code information, dependency package information, or packager information, then the version identifiers of these two software packages will be different.

[0164] In some scenarios, software packages correspond to a version number and a serial number. The version number is updated once when a major modification occurs to the information within the software package, while the serial number is updated once when a minor modification occurs. Therefore, in some embodiments, the version identifier of the first software package may include both the version number and the serial number.

[0165] In other words, in this embodiment, a combination of version number and serial number can be used as the version identifier. For any two software packages with the same name, if either the version number or the serial number is different, or if both are different, then the two software packages are considered to be different versions. Only when both the version number and the serial number are the same will the two software packages be considered to have the same version.

[0166] Alternatively, in the embodiments of this application, other information can also be used to define the version identifier of the software package, which will not be illustrated here.

[0167] In addition, in this embodiment of the application, the first installation path may be unrelated to the version identifier of the first software package.

[0168] For example, the first build script can be a build script obtained from resources in the RPM format package build technology, such as a spec file. As another example, the first build script can be a build script obtained from resources in the DEB format package build technology, such as control files and rule files. In these scenarios, the first installation path in the first build script is unrelated to the version identifier of the first package. The solution provided by the embodiments of this application can modify the first build script to generate a first package that includes a second installation path. Since the second installation path is related to the version identifier of the first package, the multi-version compatibility problem can be solved.

[0169] It should be noted that the embodiments of this application do not limit the relationship between the first installation path and multiple build elements. For example, the first installation path may be a path related to one of the build elements. In this scenario, the embodiments of this application can redirect the first installation path to a second installation path that is related to multiple build elements, so that when any of the multiple build elements of the first software package changes, it can correspond to an independent installation path.

[0170] In addition, in the embodiments of this application, the multiple build elements used to determine the second installation path may also include one or more of the following information: the source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package.

[0171] This information consists of the build elements required when building the first software package. The runtime environment typically includes information about the operating system running the package, such as the operating system version.

[0172] For example, multiple build elements may include the source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package. In this scenario, if any of these build elements changes, the final determined second installation path will be a different installation path.

[0173] For example, multiple build elements include the source code package of the first software package, the patch package of the first software package, the dependency packages of the first software package, and the runtime environment of the first software package. Suppose there are two schemes to determine the second installation path: Scheme 1: Set the second installation path based on source code package A, patch package A, dependency package A, and runtime environment A. Scheme 2: Determine the second installation path based on source code package B, patch package A, dependency package A, and runtime environment A. Since the source code packages used to determine the second installation path are different in these two schemes, the second installation paths determined by these two schemes are also different.

[0174] Furthermore, a change in the source code package of the first software package can be understood as any information within the source code package, such as a change in a certain section of code. A change in the patch package of the first software package can be understood as any information within the patch package, such as a change in a certain section of code. A change in the runtime environment of the first software package can be understood as any information about the operating system running the first software package, such as a change in its version.

[0175] In some embodiments, the second installation path includes a build element identifier, which is calculated from multiple build elements of the first software package.

[0176] Since the construction element identifier is calculated from multiple construction elements, if any one of the construction elements changes, the final calculated construction element identifier will be different. Therefore, when any one of the construction elements changes, the final determined second installation path will be a different installation path.

[0177] For example, the implementation of determining the identifier of multiple building elements can be as follows: calculate the calculation result corresponding to the multiple building elements of the first software package through a reference algorithm, and use the calculation result as the identifier of the building element. The reference algorithm can realize that the calculation result changes accordingly when any one of the multiple building elements changes.

[0178] The reference algorithm can be a hash algorithm, such as SHA256 or SHA512. Correspondingly, the calculation result can also be called the hash value or hash code of multiple building elements.

[0179] A hash algorithm is a computational process that transforms input data of arbitrary length (such as strings, files, data packets, etc.) into output data of fixed length using a specific algorithm. Hash algorithms possess a high degree of uniqueness and determinism. That is, for different input data, the hash value output by a hash algorithm is almost impossible to be the same, while for the same input data, the hash value output by a hash algorithm will definitely be the same.

[0180] Alternatively, the reference algorithm can be other algorithms with similar functions to the hash algorithm, which will not be illustrated here.

[0181] Figure 7 is a schematic diagram illustrating a scenario of calculating hash values ​​for multiple building elements of a first software package according to an embodiment of this application. It should be noted that the multiple building elements in Figure 7 are used to illustrate how to calculate hash values; this embodiment does not limit the number or type of the multiple building elements used to calculate hash values.

[0182] As shown in Figure 7, the multiple build elements of the first software package used to determine the second installation path include three aspects of information: information about the software package itself, information about the software package's dependencies, and information about the software package's runtime environment. The information about the software package itself includes the package's source code (e.g., a tarball), the package's build scripts, and the package's patch packages.

[0183] As shown in Figure 7, the steps for calculating the hash values ​​of multiple build elements include: calculating the hash value of the package itself using hash256 or hash512, and the result is labeled as package hash; calculating the hash value of the dependent packages, and the result is labeled as dependency hash; calculating the hash value of the package runtime environment, and the result is labeled as env hash (not shown in Figure 7); further calculating a total hash value from these three hash values, and using this total hash value as the hash value of these multiple build elements, which is also the build element identifier of these multiple build elements.

[0184] After obtaining the build element identifier through the above method, the first installation path in the first build script can be converted into the second installation path based on the build element identifier, so as to redirect the first installation path and obtain the second installation path.

[0185] For example, the second installation path includes the first installation path and a first extended directory located above the first installation path, the first extended directory including the build element identifier. In this scenario, redirection of the first installation path can be achieved simply by adding a first extended directory including the build element identifier above the first installation path, which is easy to implement.

[0186] Additionally, the first build script can be a build script that reuses resource acquisition techniques from rpm or deb package build technologies. In these scenarios, the first build script includes at least one macro, where each macro indicates a file directory. Accordingly, the implementation of converting the first installation path in the first build script to a second installation path based on the build element identifier can be as follows: a first extended directory is added above the file directory indicated by each macro in the first build script to obtain at least one extended macro, the first extended directory including the aforementioned build element identifier; the macros referenced in the first installation path are replaced with the corresponding extended macros to obtain the second installation path.

[0187] In other words, in this embodiment of the application, by expanding the macros in the build script, the first installation path in the first build script can be redirected to obtain a second installation path related to multiple build elements.

[0188] Taking a spec file as an example, the macros included in the first build script are as follows:

[0189] _prefix: / usr

[0190] _sysconfdir: / etc

[0191] _sbindir: / sbin

[0192] _bindir: / bin

[0193] An example of a macro expanded in the above manner is shown below:

[0194] _prefix:%{_epkg_prefix} / usr

[0195] _sysconfdir:%{_epkg_prefix} / etc

[0196] _sbindir:%{_exec_prefix} / sbin

[0197] _bindir:%{_exec_prefix} / bin

[0198] The `_epkg_prefix` and `_exec_prefix` include the build element identifiers calculated using the reference algorithm. Thus, as shown in Figure 8, the path in the section beginning with `%install` in the build script is redirected from the first installation path to the second installation path.

[0199] Furthermore, as shown in Figure 8, because the macros in the spec file have been expanded, the macros referenced in other paragraphs of the build script are also replaced with the corresponding expanded macros to complete the overall transformation of the first build script. For example, the macros referenced in the paragraph starting with %build (regarding the location of the configure parameters), the macros referenced in the paragraph starting with %files (regarding the location of the files), and the macros referenced in the paragraph starting with %changelog are all replaced with expanded macros to obtain the modified second build script. The functions of these paragraphs have been described above and will not be repeated here.

[0200] Additionally, as shown in Figure 8, the spec file may also include a paragraph starting with %pre and a paragraph starting with %post. The information following %pre indicates the storage path of scripts to be executed before installing the first software package, and the information following %post indicates the storage path of scripts to be executed after installing the first software package. As shown on the left side of Figure 8, the storage paths of these scripts are usually fixed. In this embodiment, the scripts indicated in the paragraph starting with %pre are called pre-installation execution scripts, and the scripts indicated in the %post paragraphs are called post-installation execution scripts. The storage paths of the scripts in the paragraphs starting with %pre and %post in the spec file on the left side of Figure 8 are simply referred to as the default script storage paths.

[0201] In this embodiment of the application, in order to further improve the application flexibility of the pre-installation execution script and the post-installation execution script, the default script storage path can be redirected. As shown in the spec file on the right side of Figure 8, a second extended directory is added above the default script storage path. At this time, the added second extended directory is related to the code in the pre-installation execution script and the post-installation execution script.

[0202] In other words, the first build script includes a first storage path for the target script, which is either executed before or after the first software package is installed. The modified second build script includes a second storage path for the target script, and this second storage path is related to the code within the target script.

[0203] For example, the second storage path includes the first storage path and a second extended directory located above the first storage path, the second extended directory being associated with the code in the target script.

[0204] For example, a hash calculation is performed on the code in the target script, and a second extended directory is set based on the calculated hash value. As shown in Figure 8, `opt / epkg / ${bash_prefix}` and `opt / epkg / ${elibc_prefix}` both represent a second extended directory. Here, `bash_prefix` is obtained by hashing the code in a script executed before installation, and `elibc_prefix` is obtained by hashing the code in a script executed after installation.

[0205] Alternatively, the default script storage paths for pre-installation and post-installation scripts can be left unredirected, and the default script storage paths in the spec file on the left side of Figure 8 can be retained. In this scenario, since these scripts are already installed in the operating system's user environment before the first software package is installed, the default script storage paths in the spec file on the left side of Figure 8 can be mounted into the operating system's user environment using a transparent container, allowing the installed scripts to be directly located in the user environment.

[0206] Step 503: Build a first software package based on the second build script. The first software package contains the second installation path.

[0207] After obtaining the second build script, a package build tool can be invoked to generate the first package using the second build script. This application embodiment does not limit the implementation of step 503. For example, the rpmbuild tool can be invoked to generate the first package based on the second build script.

[0208] The first software package carries a second installation path, allowing subsequent user installations of the first software package according to this path. Since the second installation path is associated with multiple build elements of the first software package, the first software package can be installed into a path related to multiple build elements, rather than a fixed path associated only with the package name. Correspondingly, for two software packages with the same name but different build elements, their second installation paths will be different, allowing them to be installed together on the same operating system. Therefore, the method provided in this application can modify the build scripts of software packages in formats such as rpm and deb to improve the application flexibility of these software packages on the Linux operating system.

[0209] In addition, after the first software package is generated by the software package build tool, if the dependent packages of the first software package are also installed in the installation path related to multiple build elements, the installation path of the dependent packages can be built into the first software package to facilitate accurate location of the dependent packages when installing or running the first software package later.

[0210] Based on this, in some embodiments, when the first software package corresponds to at least one dependent package, and the at least one dependent package includes the first dependent package, the first software package may also contain first dependent configuration information, the first dependent location information carries a third installation path, the third installation path is the installation path of the first dependent package, and the third installation path is related to multiple build elements of the first dependent package.

[0211] For example, the first dependency configuration information is a list of dependency package names of the first software package. This list of dependency package names includes the names of each dependency package of the first software package. The dependency package name of the first dependency package is an extended name, which may include not only the name of the first dependency package itself, but also a third installation path.

[0212] In this scenario, when building the first dependency package, you can set its name (soname) to an extended name so that the extended name includes the third installation path of the first dependency package. Alternatively, when building the first software package, you can extend the name of the first dependency package recorded in the first software package so that the extended name includes the third installation path of the first dependency package.

[0213] For example, the first dependency configuration information is the runtime search path (runpath) of the first software package. The runtime search path is a file used to specify the query location of dependency packages. Thus, when the first software package is subsequently installed or run, the third installation path of the first dependency package can be found from the runtime link path, and consequently, the first dependency package can be located.

[0214] The third installation path of the first dependency package can be embedded in the runtime link path, which can be achieved using the patchelf tool. This will not be explained in detail here.

[0215] For another example, the first dependency configuration information is the ld.config.cache file of the first software package. ld.config.cache is also a file used to specify the query location of dependency packages. In this scenario, the third installation path of the first dependency package is built into ld.config.cache, so that when the first software package is installed or run later, the third installation path of the first dependency package can be found in ld.config.cache, and thus the first dependency package can be found.

[0216] It should be noted that the first dependency package can be a library built into the first software package. In this scenario, the third installation path in the first dependency configuration information above is the same as the second installation path in step 502.

[0217] In addition, in the embodiments of this application, during the process of building the first software package based on the second build script, a software bill of material (SBOM) of the first software package can also be generated. The SBOM is used to record the elements used in the process of building the first software package; the SBOM is embedded in the first software package; or, the tags of the SBOM are embedded in the first software package.

[0218] In other words, the first software package constructed through the embodiments of this application contains a built-in Software Bill of Materials (SBOM) or a label of the SBOM.

[0219] The SBOM (Software Component Ownership Model) is a detailed list of all elements used in the software package build process. These elements include open-source software components, third-party libraries, frameworks, tools, and more. Each element has detailed information in the SBOM, such as its name, version number, license information, and dependencies.

[0220] The purpose of a Software Build Item (SBOM) is to increase visibility and transparency in the software supply chain and provide better risk management and security. It helps software developers, vendors, and users understand all elements used in the first software package build process, enabling better management of potential vulnerabilities, security risks, and compliance issues. Furthermore, through the SBOM, users can identify and track any potential vulnerabilities or known security issues in the first software package and take timely remedial measures.

[0221] Additionally, the SBOM's tag is used to uniquely identify the SBOM. When the SBOM's tag is embedded in the first software package, the mapping relationship between the SBOM's tag and the SBOM itself also needs to be stored. Later, when maintenance personnel need to query the SBOM of the first software package, they can first retrieve the SBOM's tag from the first software package, and then find the SBOM based on this mapping relationship.

[0222] It should be noted that some organizations have specified the fields that must be included in the SBOM. In other words, some organizations provide SBOM templates. Therefore, during the construction of the first software package, the values ​​corresponding to each field in the SBOM template can be directly obtained, and then the values ​​are updated in the SBOM template to obtain the SBOM of the first software package.

[0223] Figure 9 is a schematic diagram of an SBOM provided in an embodiment of this application. In each row, the element to the left of the right arrow symbol is a single element, and the value to the right of the right arrow symbol is the value of that element. Figure 9 illustrates an SBOM in System Package Data Exchange (SPDX) format, but this embodiment does not limit the SBOM format.

[0224] The SPDX format is a specification for describing software packages. It provides a standardized way to describe the metadata of software packages, including their licenses, dependencies, and other attributes.

[0225] As shown in Figure 9, the SBOM records not only basic information from the YAML-formatted software specification used when building the first software package, such as the package name, version number, and license, but also elements used in the package building process, such as source packages and dependency packages. Furthermore, the SBOM also records relevant descriptions of the completed first software package.

[0226] In this embodiment, the values ​​of certain elements in the SBOM can be determined based on the hash values ​​of the corresponding elements, so that the corresponding elements can be accurately found based on the values. As shown in Figure 9, SPDXID represents the identifier of the current package, and the value of this identifier can be generated based on the hash value (current_package_hash) of the first package. It should be noted that the method for determining the hash value of the first package here can be the same as that for calculating the hash values ​​of multiple building elements in step 502, or it can be different, as long as current_package_hash can uniquely identify the first package.

[0227] For information on the other fields in Figure 9, please refer to the relevant SPDX standards; examples will not be provided here.

[0228] After the first software package is completed through steps 501 to 503, it can be stored in the software repository management subsystem shown in Figure 1 so that users can download and install it through the package management subsystem.

[0229] The package management subsystem can be understood as a special software package installed on the operating system. Users can manage other software packages running on the operating system through the package management subsystem. The package management subsystem can also be called a package manager.

[0230] In this embodiment, when a user downloads and installs the package management subsystem from the software repository management subsystem, the software repository management subsystem packages the package management subsystem, analyzes all its dependencies, and adds all dependencies to the packaged file. This ensures that the user downloads all dependencies of the package management subsystem simultaneously, guaranteeing its proper operation. This process can be referred to as the green installation function of the package management subsystem.

[0231] In addition, this application also provides a method for managing software packages through a package management subsystem. The method is explained below.

[0232] Figure 10 illustrates a method for managing software packages according to an embodiment of this application. This method is exemplarily applied to the package management subsystem in the user terminal shown in Figure 3. As shown in Figure 10, the method includes the following steps.

[0233] Step 1001: Obtain the first software package, which carries a second installation path. The first software package is built based on the second build script, which is determined based on the first build script. The first build script includes a first installation path. Both the first and second installation paths are used to indicate the installation location of the target files. The target files are files compiled during the process of building the first software package, and the second installation path is related to multiple build elements of the first software package.

[0234] In some embodiments, the package management subsystem provides a package download interface, which includes a download option for a first package. When a user triggers this download option, the package management subsystem sends a package download request to the software repository management subsystem. This download request carries an identifier for the first package, which, for example, includes the name and version number of the first package. The software repository management subsystem locates the first package based on its identifier and returns the found package to the package management subsystem, enabling the package management subsystem to obtain the first package.

[0235] Step 1002: Install and run the first software package according to the second installation path.

[0236] In some embodiments, step 1002 can be implemented as follows: adding the first software package to the operating system according to the second installation path, and creating a user environment on the operating system; establishing a soft link between the first path in the user environment and the second installation path; and running the first software package in the user environment via the first path.

[0237] When multiple user environments are created on the operating system, users in any user environment can run the first software package in their respective user environment using the method described above. For example, if user environment 1 and user environment 2 are created on the operating system, and a user in user environment 1 first installs and runs the first software package through step 1002, when a user in user environment 2 installs and runs the first software package again through step 1002, since the first software package is still added to the operating system via the second installation path, the software package management subsystem will detect that the first software package has already been added to the operating system. Therefore, it is not necessary to add it again; only a symbolic link needs to be established between the first path in user environment 2 and the second installation path. This allows the first software package to be added only once on the same operating system, and run through the corresponding first path in different user environments. This avoids the need to repeatedly add the first software package to the operating system, thus saving operating system storage space.

[0238] Adding the first software package to the operating system according to the second installation path can be understood as adding the object files of the first software package to the location indicated by the second installation path in the operating system. Other files in the first software package are added to the operating system in the same way to achieve the purpose of adding the first software package to the operating system.

[0239] Understandably, the second installation path consists of file directories at different levels. For example, the second installation path might be ` / opt / epkg / store / $hash-bash-$ver / bin / bash`, where `opt`, `epkg`, `store`, `$hash-bash-$ver`, `bin`, and `bash` each point to a file directory. In this scenario, before adding the object files from the first software package to the location indicated by the second installation path in the operating system, if the various file directories in the second installation path do not exist in the operating system, the package management subsystem will first create these file directories in the operating system.

[0240] In addition, in some embodiments, the user environment is configured with a file directory structure based on the file system hierarchy standard (FHS), and the first path is a path under that file directory structure.

[0241] Since the user runs the first software package through a first path, which is a path under the FHS file directory structure, this embodiment of the application, even with a modified installation path, can still run the first software package through a path under the FHS file directory structure, thus achieving compatibility with FHS. This solves the current problem of incompatibility between Nix technology and FHS.

[0242] The file directory structure can be understood as the organization of file directories in the user environment. The File System Hierarchy (FHS) uses a tree structure to organize file directories. The FHS defines each file directory and its function. For example, the FHS defines file directories such as the root directory, user directory, and var directory, and configures what kind of data should be placed in each file directory.

[0243] For example, in a first user environment, a first file directory structure based on the FHS is created, and a symbolic link is established between a first path A in the first file directory structure and a second installation path. In this way, the user in the first user environment can run the first software package through the first path A. Similarly, in a second user environment, a second file directory structure based on the FHS is created, and a symbolic link is established between a first path B in the second file directory structure and a second installation path. In this way, the user in the second user environment can run the first software package through the first path B.

[0244] Figure 11 is a schematic diagram of a multi-user environment provided in an embodiment of this application. As shown in Figure 11, assuming that user environment 1 and user environment 2 are created in the operating system, in user environment 1, a soft link is established between a first path and a second installation path in user environment 1, so that users in user environment 1 can run the first software package through the first path in user environment 1. In user environment 2, a soft link is established between a first path and a second installation path in user environment 2, so that users in user environment 2 can run the first software package through the first path in user environment 2.

[0245] It should be noted that the first software package contains multiple files. For the other files in the first software package besides the target file, symbolic links can be created in the user's environment in the same way as the target file.

[0246] As shown in Figure 11, the file directory structures created in User Environment 1 and User Environment 2 include directories such as etc, usr, bin, lib, and var. Assuming that a file in the first software package, such as the target file, is installed in the operating system's directory as / opt / epkg / store / $hash-bash-$ver / bin / bash (i.e., the second installation path), symbolic links can be created between the first path in the file directory structure of User Environment 1 and / opt / epkg / store / $hash-bash-$ver / bin / bash, and between the first path in the file directory structure of User Environment 2 and / opt / epkg / store / $hash-bash-$ver / bin / bash, so that the user can run the target file in the first software package normally in both User Environment 1 and User Environment 2.

[0247] Additionally, during the execution of the first software package, if the operating system needs to run its dependent packages, the loader on the operating system will locate the installation path of the dependent packages and then run them according to that path. As shown in Figure 11, the operating system is configured with a dynamic link library containing two dependent packages of the first software package. The installation paths of these two dependent packages are $hash-glibc-$ver / lib / lib.so.6 and $hash-glibc-$ver / lib / libpthread.so.0, respectively.

[0248] The embodiments shown in Figures 5 and 10 will be described in general with reference to Figure 12. It should be noted that Figure 12 is used to illustrate the embodiments of this application, and Figure 12 does not constitute a limitation on the embodiments shown in Figures 5 and 10.

[0249] As shown in Figure 12, the first software package to be built is labeled "glibc-3.x". The macros in the obtained first build script are modified by extending the built-in macros in the build script. Then, the first software package is built according to the modified second build script. Assuming that the first and second build scripts are of type spec files, the build operation can be completed using the rpmbuild tool.

[0250] After the developers have built the first software package, any user in any user environment, such as a user in user environment 1, can download the first software package and add the various files from the first software package to their operating system according to the second installation path. As shown in Figure 12, the installation path of each file includes a first extended directory " / opt / epkg / $hash-glibc-3.x", and "$hash" in the first extended directory is the hash value of multiple build elements of the first software package.

[0251] After adding the first software package to the operating system according to the second installation path, the user in user environment 1 can establish a soft link between the first path and the second installation path in user environment 1, so that the user in user environment 1 can run the first software package through the first path in user environment 1.

[0252] Accordingly, when a user in user environment 2 downloads the first software package and adds it to the operating system according to the second installation path, since the user in user environment 1 has already added the first software package to the operating system, the first software package will not be added to the operating system again. However, a symbolic link between the first path and the second installation path will be created in user environment 2 so that the user in user environment 2 can run the first software package through the first path in user environment 2.

[0253] Furthermore, based on the foregoing, for any dependent package of the first software package, such as the first dependent package itself, the first software package constructed in this application embodiment may also include first dependency configuration information, which includes a third installation path for the first dependent package. Therefore, before installing the first software package in the operating system, the first dependent package can be searched for according to the third installation path. If the first dependent package cannot be found, it is installed in the operating system according to the third installation path.

[0254] Based on this, in some embodiments, when the first dependency package is updated, the installation path of the updated first dependency package is obtained to obtain the fourth installation path; the third installation path in the first dependency configuration information is updated to the fourth installation path to obtain the updated first software package.

[0255] The aforementioned update of the installation path of the first dependency package can be implemented on either the development or user side. On the development side, developers can update the third installation path built into the first software package within the software repository management subsystem, and users will subsequently download the updated first software package. On the user side, after running the first software package on the operating system through the software package management subsystem, the user can update the first software package added to the operating system using the aforementioned method of updating the installation path of the first dependency package to ensure the normal operation of the first software package.

[0256] In addition, after the package management subsystem installs the first dependency package on the operating system, it will add the third installation path to the second dependency configuration information in the user environment. The second dependency configuration information can also be id.config.cache in the user environment.

[0257] Therefore, in some other embodiments, after the first software package runs on the operating system, if the first dependency package is updated, the software package management subsystem can directly modify the second dependency configuration information to update the fourth installation path to the second dependency configuration information. In this scenario, it is not necessary to update the first dependency configuration information built into the first software package.

[0258] It should be noted that the second dependency configuration information is different from the aforementioned first dependency configuration information. The first dependency configuration information is the dependency configuration information built into the first software package, while the second dependency configuration information is the dependency configuration information set in the user's environment. When running the first software package, the loader first searches for the first dependency package in the second dependency configuration information. If it cannot find it, it continues to search for the first dependency package in the first dependency configuration information. Therefore, when the first dependency package is updated, the second dependency configuration information can be updated directly in the user's environment.

[0259] Furthermore, if the installation path of a dependency package is specified in the source code of the first software package, that is, the installation path of the dependency package is hardcoded in the source code, then when the first software package is run, the loader on the operating system will directly search for the dependency package from the specified installation path. However, in the embodiments of this application, if the actual installation path of the dependency package is also a path related to multiple build elements of the dependency package, such as version identifiers, then the dependency package may not be found or may be found incorrectly at the specified installation path. For example, if the dependency package is not installed at the specified installation path, then the dependency package will not be found when running the first software package. Or, for example, if the first software package requires a dependency package of version 1, but the version of the dependency package installed at the specified installation path is version 2, then the dependency package will be found incorrectly when running the first software package.

[0260] Based on this, if the first software package corresponds to at least one dependent package, and at least one dependent package includes a second dependent package, and the source code information in the first software package includes the specified installation path of the second dependent package, and the source code information is the information after compiling the source code package of the first software package, then the specified installation path can be mounted to a second path in the user's environment. The second path is used to store the second dependency configuration information, and the second dependency configuration information is used to record the installation path of the second dependent package. Accordingly, during the execution of the first software package, the second dependent package is searched for in the second dependency configuration information through the second path.

[0261] It should be noted that when installing the first software package on the operating system, for any dependency package of the first software package, the system first checks whether the dependency package is installed on the operating system. If the dependency package is not on the operating system, it must be installed first. If the first software package contains the installation path of the dependency package, it will be installed according to the built-in installation path. Simultaneously, dependency configuration information, also known as second dependency configuration information, is generated in the user environment. The second dependency configuration information includes the installation path of the dependency package. Therefore, during the running of the first software package, when looking for the installation path of a dependency package in the user environment, the actual installation path of the dependency package can be found in the second dependency configuration information.

[0262] The function implemented by the above mounting process can be called a transparent container. By using a transparent container, when the loader runs the first software package, it does not see the original specified installation path of the second dependency package, but instead sees the mounted second path. Then, it searches for the aforementioned second dependency configuration information in the user environment through the second path, and finds the second dependency package through the installation path of the second dependency package recorded in the second dependency configuration information.

[0263] One way to mount the specified installation path to the second path is to mount the root directory of the specified installation path to the target directory of the second path, where the target directory is, for example, the parent directory of the second path.

[0264] For example, if the installation path is specified as usr / lib / _so, where _so is the name of the second dependency package, then the root directory of the installation path is usr, and the second path is env / usr / lib / . This allows mounting / usr to env / usr.

[0265] The above mounting can be achieved using the `mount` or `unshare` command. This application does not limit this approach.

[0266] Furthermore, as shown in the embodiment of Figure 5, the first software package may also contain a Software Bill of Materials (SBOM) or SBOM tags. The SBOM records the elements used during the construction of the first software package. In this scenario, the method retrieves the SBOM or SBOM tags from the first software package and determines the security vulnerabilities of the first software package based on the SBOM or SBOM tags.

[0267] Because the first software package contains a built-in SBOM or SBOM tag, the user client can detect security vulnerabilities in the first software package based on the SBOM or SBOM tag after running the first software package. The method for identifying security vulnerabilities in the first software package has already been explained above and will not be repeated here.

[0268] In summary, in this embodiment, after obtaining the first build script, to avoid the first installation path in the first build script being a fixed path solely related to the package name, the first build script is modified. The modified second build script then includes a second installation path related to multiple build elements of the first package. Thus, the first package can be installed to a path associated with multiple build elements, rather than a fixed path solely related to the package name. Consequently, for two packages with the same name but different build elements, their second installation paths will be different, allowing them to be installed together on the same operating system. Therefore, the method provided in this embodiment can modify the build scripts of packages in formats such as rpm and deb, improving the application flexibility of these packages on the Linux operating system.

[0269] Furthermore, these multiple build elements include the package version identifier. Thus, when the package version identifier changes, the package installation path will change, enabling the installation of multiple packages with the same name but different versions on the same operating system, thereby resolving multi-version compatibility issues. On one hand, by specifying an installation path associated with the version identifier to solve multi-version compatibility problems, it is unnecessary to package the dependency packages themselves inside the package, thus avoiding the problems that occur when dependency packages are directly packaged inside the package in technologies such as Snap and Flatpak. On the other hand, the method provided in this application embodiment only requires modification of the obtained first build script. Therefore, resources from existing package building technologies can be reused to obtain the first build script, such as reusing resources from rpm or deb package building technologies, and then redirecting the first installation path in the first build script to a second installation path associated with the version identifier. Therefore, this application embodiment does not require writing build scripts in a custom language to configure an independent installation path for each version of the package, as is required in NIX technologies, thus reducing the learning cost.

[0270] Furthermore, embodiments of this application may also embed a Security Module Object (SBOM) in the first software package. Subsequently, after running the first software package, the SBOM can be used to analyze any security vulnerabilities present in the first software package.

[0271] Furthermore, embodiments of this application can also achieve the goal of adding the first software package only once on the same operating system, allowing it to run in different user environments. Moreover, the file directory structure configured in each user environment can be based on the FHS file directory structure, thus ensuring compatibility with the current FHS even when the installation path of the software package is modified. This solves the current problem of incompatibility between Nix technology and FHS.

[0272] Furthermore, embodiments of this application can also use a transparent container to resolve corner cases that occur when the installation paths of dependency packages are hardcoded in the source code package.

[0273] Furthermore, in this embodiment of the application, when the dependent packages of the first software package are updated, the installation path of the dependent packages can be updated without recompiling the entire first software package, thus improving the efficiency of software package updates.

[0274] Figure 13 is a schematic diagram of a device for building software packages provided in an embodiment of this application. As shown in Figure 13, the device 1300 includes the following modules.

[0275] The acquisition module 1301 is used to acquire a first build script for building the first software package. The first build script includes a first installation path, which indicates the installation location of the target file. The target file is a file compiled during the process of building the first software package. For detailed implementation, please refer to step 501 in the embodiment of Figure 5.

[0276] The determination module 1302 is used to determine a second build script based on the first build script. The second build script includes a second installation path, which is used to indicate the installation location of the target file and is related to multiple build elements of the first software package. For detailed implementation, please refer to step 502 in the embodiment of Figure 5.

[0277] Module 1303 is used to build a first software package based on a second build script. The first software package carries a second installation path. For detailed implementation, please refer to step 503 in the embodiment of Figure 5.

[0278] Optionally, build elements are used to build the first software package.

[0279] Optionally, the second installation path includes a build element identifier, which is calculated from multiple build elements of the first software package.

[0280] Optionally, the second installation path includes the first installation path and a first extended directory located above the first installation path, the first extended directory including build element identifiers.

[0281] Optionally, multiple build elements of the first software package include a version identifier for the first software package.

[0282] Optionally, the version identifier of the first software package includes the version number and release number of the first software package.

[0283] Optionally, the first installation path is independent of the version identifier of the first software package.

[0284] Optionally, the multiple build elements of the first software package include at least one of the following: the source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package.

[0285] Optionally, the first software package corresponds to at least one dependency package, and the at least one dependency package includes the first dependency package; the first software package contains first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependency package, and the third installation path is related to multiple build elements of the first dependency package.

[0286] Optionally, the first software package may contain a built-in Software Bill of Materials (SBOM) or a label for the SBOM, which records the elements used during the construction of the first software package.

[0287] Optionally, the acquisition module is used to: acquire the source code package of the first software package from the software package source code repository, and determine the first build script based on the source code package; or, acquire the software artifact of the first software package from the software artifact repository, and determine the first build script based on the software artifact; or, acquire the already built second software package, and determine the first build script based on the second software package, wherein the second software package has the same name as the first software package.

[0288] It should be noted that the apparatus for building software packages provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus for building software packages and the method embodiments for building software packages provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0289] Figure 14 is a schematic diagram of a management software package device provided in an embodiment of this application. As shown in Figure 14, the device 1400 includes the following modules.

[0290] The first acquisition module 1401 is used to acquire a first software package, which carries a second installation path. The first software package is built based on a second build script, which is determined based on the first build script. The first build script includes a first installation path. Both the first and second installation paths are used to indicate the installation location of the target file. The target file is a file compiled during the construction of the first software package, and the second installation path is related to multiple build elements of the first software package. For detailed implementation, please refer to step 1001 in the embodiment of Figure 10.

[0291] The runtime module 1402 is used to install and run the first software package according to the second installation path. For detailed implementation, please refer to step 1002 in the embodiment shown in Figure 10.

[0292] Optionally, the runtime module is used to: add the first software package to the operating system according to the second installation path, on which a user environment is created; establish a symbolic link between the first path in the user environment and the second installation path; and run the first software package in the user environment via the first path.

[0293] Optionally, the user environment is configured with a file directory structure based on the File System Hierarchy Standard (FHS), where the first path is a path under the file directory structure.

[0294] Optionally, the first software package corresponds to at least one dependent package, the at least one dependent package includes the first dependent package, the first software package contains built-in first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependent package, and the third installation path is related to multiple build elements of the first dependent package; the device further includes: a second acquisition module, used to acquire the updated installation path of the first dependent package to obtain a fourth installation path when the first dependent package is updated; an update module, used to update the third installation path carried by the first dependency configuration information to the fourth installation path to obtain an updated first software package; or, update the fourth installation path to the second dependency configuration information, the second dependency configuration information being dependency configuration information set in the user environment running the first software package.

[0295] Optionally, the first software package corresponds to at least one dependent package, and the at least one dependent package includes a second dependent package. The source code information in the first software package includes a specified installation path of the second dependent package, and the source code information is compiled from the source code package of the first software package. The device further includes: a mounting module, used to mount the specified installation path to a second path in the user environment running the first software package, the second path being used to store second dependency configuration information, and the second dependency configuration information being used to record the installation path of the second dependent package; and a lookup module, used to look up the installation path of the second dependent package in the second dependency configuration information through the second path during the running of the first software package.

[0296] Optionally, the first software package contains a built-in Software Bill of Materials (SBOM) or a label for the SBOM, which is used to record the elements used in the construction process of the first software package; the device further includes: a third acquisition module for acquiring the SBOM or the label for the SBOM from the first software package;

[0297] The determination module is used to determine the security vulnerabilities of the first software package based on the SBOM or the SBOM's tags.

[0298] It should be noted that the above embodiments of the management software package apparatus are only illustrative examples of the division of the above functional modules when managing the software package. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the management software package apparatus and the management software package method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0299] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0300] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0301] The above content is not intended to limit the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A method for building a software package, characterized in that, The method includes: Obtain a first build script for building a first software package. The first build script includes a first installation path, which indicates the installation location of a target file, wherein the target file is a file compiled during the process of building the first software package. A second build script is determined based on the first build script. The second build script includes a second installation path, which indicates the installation location of the target file and is associated with multiple build elements of the first software package. The first software package is built based on the second build script, and the first software package carries the second installation path.

2. The method as described in claim 1, characterized in that, The building elements are used to build the first software package.

3. The method as described in claim 1 or 2, characterized in that, The first software package includes multiple build elements, including a version identifier for the first software package.

4. The method as described in claim 3, characterized in that, The version identifier of the first software package includes the version number and release number of the first software package.

5. The method as described in claim 3 or 4, characterized in that, The first installation path is unrelated to the version identifier of the first software package.

6. The method according to any one of claims 1-5, characterized in that, The first software package includes at least one of the following build elements: The source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package.

7. The method according to any one of claims 1-6, characterized in that, The second installation path includes a build element identifier, which is calculated from multiple build elements of the first software package.

8. The method as described in claim 7, characterized in that, The second installation path includes the first installation path and a first extended directory located above the first installation path, wherein the first extended directory includes the build element identifier.

9. The method according to any one of claims 1-8, characterized in that, The first software package has at least one dependency package, and the at least one dependency package includes the first dependency package; The first software package contains first dependency configuration information, which carries a third installation path. The third installation path is the installation path of the first dependency package and is related to multiple build elements of the first dependency package.

10. The method according to any one of claims 1-9, characterized in that, The first software package contains a built-in Software Bill of Materials (SBOM) or a tag of the SBOM, which is used to record the elements used in the construction process of the first software package.

11. The method according to any one of claims 1-10, characterized in that, The step of obtaining the first build script for building the first software package includes: Obtain the source code package of the first software package from the software package source code repository, and determine the first build script based on the source code package; or, Obtain the software artifact of the first software package from the software artifact repository, and determine the first build script based on the software artifact; or... Obtain the second package that has already been built, and determine the first build script based on the second package, wherein the second package has the same name as the first package.

12. A method for managing software packages, characterized in that, The method includes: Obtain a first software package, which carries a second installation path. The first software package is built based on a second build script, which is determined based on a first build script. The first build script includes a first installation path. Both the second installation path and the first installation path are used to indicate the installation location of the target file. The target file is a file compiled during the process of building the first software package. The second installation path is related to multiple build elements of the first software package. Install and run the first software package according to the second installation path.

13. The method as described in claim 12, characterized in that, The step of installing and running the first software package according to the second installation path includes: The first software package is added to the operating system according to the second installation path, and a user environment is created on the operating system. Establish a symbolic link between the first path in the user environment and the second installation path; The first software package is run through the first path in the user environment.

14. The method as described in claim 13, characterized in that, The user environment is configured with a file directory structure based on the File System Hierarchy Standard (FHS), and the first path is a path under the file directory structure.

15. The method according to any one of claims 12-14, characterized in that, The first software package corresponds to at least one dependency package, the at least one dependency package includes a first dependency package, the first software package contains first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependency package, and the third installation path is related to multiple build elements of the first dependency package; The method further includes: If the first dependency package is updated, obtain the installation path of the updated first dependency package to get the fourth installation path; Update the third installation path carried in the first dependency configuration information to the fourth installation path to obtain the updated first software package; or, The fourth installation path is updated to the second dependency configuration information, which is the dependency configuration information set in the user environment running the first software package.

16. The method according to any one of claims 12-15, characterized in that, The first software package has at least one dependent package, and the at least one dependent package includes a second dependent package. The source code information in the first software package includes the specified installation path of the second dependent package. The source code information is compiled from the source code package of the first software package. The method further includes: The specified installation path is mounted to a second path in the user environment running the first software package. The second path is used to store the second dependency configuration information, and the second dependency configuration information is used to record the installation path of the second dependency package. During the execution of the first software package, the installation path of the second dependency package is located in the second dependency configuration information through the second path.

17. The method according to any one of claims 12-16, characterized in that, The first software package contains a built-in Software Bill of Materials (SBOM) or a tag of the SBOM, which is used to record the elements used in the construction process of the first software package; The method further includes: Obtain the SBOM or the tag of the SBOM from the first software package; The security vulnerability of the first software package is determined based on the SBOM or the label of the SBOM.

18. An apparatus for building software packages, characterized in that, The device includes: The acquisition module is used to acquire a first build script for building a first software package. The first build script includes a first installation path, which is used to indicate the installation location of a target file. The target file is a file compiled during the process of building the first software package. A determination module is used to determine a second build script based on the first build script. The second build script includes a second installation path, which indicates the installation location of the target file and is associated with multiple build elements of the first software package. A build module is used to build the first software package based on the second build script, wherein the first software package carries the second installation path.

19. The apparatus as claimed in claim 18, characterized in that, The building elements are used to build the first software package.

20. The apparatus as claimed in claim 18 or 19, characterized in that, The first software package includes multiple build elements, including a version identifier for the first software package.

21. The apparatus as claimed in claim 20, characterized in that, The version identifier of the first software package includes the version number and release number of the first software package.

22. The apparatus as claimed in claim 20 or 21, characterized in that, The first installation path is unrelated to the version identifier of the first software package.

23. The apparatus according to any one of claims 18-22, characterized in that, The first software package includes at least one of the following build elements: The source code package of the first software package, the patch package of the first software package, the dependency package of the first software package, the first build script, and the runtime environment of the first software package.

24. The apparatus according to any one of claims 18-23, characterized in that, The second installation path includes a build element identifier, which is calculated from multiple build elements of the first software package.

25. The apparatus as claimed in claim 24, characterized in that, The second installation path includes the first installation path and a first extended directory located above the first installation path, wherein the first extended directory includes the build element identifier.

26. The apparatus according to any one of claims 18-25, characterized in that, The first software package has at least one dependency package, and the at least one dependency package includes the first dependency package; The first software package contains first dependency configuration information, which carries a third installation path. The third installation path is the installation path of the first dependency package and is related to multiple build elements of the first dependency package.

27. The apparatus according to any one of claims 18-26, characterized in that, The first software package contains a built-in Software Bill of Materials (SBOM) or a tag of the SBOM, which is used to record the elements used in the construction process of the first software package.

28. The apparatus according to any one of claims 18-27, characterized in that, The acquisition module is used for: Obtain the source code package of the first software package from the software package source code repository, and determine the first build script based on the source code package; or, Obtain the software artifact of the first software package from the software artifact repository, and determine the first build script based on the software artifact; or, Obtain the second package that has already been built, and determine the first build script based on the second package, wherein the second package has the same name as the first package.

29. An apparatus for managing software packages, characterized in that, The device includes: A first acquisition module is used to acquire a first software package, which carries a second installation path. The first software package is built based on a second build script, which is determined based on a first build script. The first build script includes a first installation path. Both the second installation path and the first installation path are used to indicate the installation location of a target file. The target file is a file compiled during the process of building the first software package, and the second installation path is related to multiple build elements of the first software package. The runtime module is used to install and run the first software package according to the second installation path.

30. The apparatus as claimed in claim 29, characterized in that, The operating module is used for: The first software package is added to the operating system according to the second installation path, and a user environment is created on the operating system. Establish a symbolic link between the first path in the user environment and the second installation path; The first software package is run through the first path in the user environment.

31. The apparatus as claimed in claim 30, characterized in that, The user environment is configured with a file directory structure based on the File System Hierarchy Standard (FHS), and the first path is a path under the file directory structure.

32. The apparatus according to any one of claims 29-31, characterized in that, The first software package corresponds to at least one dependency package, the at least one dependency package includes a first dependency package, the first software package contains first dependency configuration information, the first dependency configuration information carries a third installation path, the third installation path is the installation path of the first dependency package, and the third installation path is related to multiple build elements of the first dependency package; The device further includes: The second acquisition module is used to obtain the installation path of the updated first dependency package when the first dependency package is updated, and thus obtain the fourth installation path. An update module is used to update the third installation path carried in the first dependency configuration information to the fourth installation path to obtain an updated first software package; or, to update the fourth installation path to the second dependency configuration information, wherein the second dependency configuration information is the dependency configuration information set in the user environment running the first software package.

33. The apparatus according to any one of claims 29-32, characterized in that, The first software package has at least one dependent package, and the at least one dependent package includes a second dependent package. The source code information in the first software package includes the specified installation path of the second dependent package. The source code information is compiled from the source code package of the first software package. The device further includes: The mounting module is used to mount the specified installation path to a second path in the user environment running the first software package. The second path is used to store second dependency configuration information, and the second dependency configuration information is used to record the installation path of the second dependency package. The search module is used to search for the installation path of the second dependency package in the second dependency configuration information through the second path during the running of the first software package.

34. The apparatus according to any one of claims 29-33, characterized in that, The first software package contains a built-in Software Bill of Materials (SBOM) or a tag of the SBOM, which is used to record the elements used in the construction process of the first software package; The device further includes: The third acquisition module is used to acquire the SBOM or the tag of the SBOM from the first software package; A determination module is used to determine the security vulnerabilities of the first software package based on the SBOM or the tags of the SBOM.

35. A computer device, characterized in that, The computer device includes a processor and memory; The processor is configured to execute instructions stored in the memory to cause the computer device to perform the method as described in any one of claims 1-11 or the method as described in any one of claims 12-17.

36. A computer program product containing instructions, characterized in that, When the instructions are executed by the computing device, the computing device performs the method as described in any one of claims 1-11, or performs the method as described in any one of claims 12-17.

Images