Method for constructing software package, method for managing software package, device and related product

Abstract

The embodiment of the application discloses a kind of method for constructing software package, the method for managing software package, device and related product, belong to computer technical field.In the method, after obtaining first construction script, first construction script is reformed, and the second installation path in the second construction script after reformation is related to the multiple construction elements of first software package.So, first software package can be installed in one path related to multiple construction elements, instead of being installed in a fixed path only related to software package name.Correspondingly, for two software packages belonging to the same name but different between multiple construction elements, the second installation path of the two software packages will be different, so that the two software packages can be installed together on the same operating system.Therefore, the embodiment of the application can reform the construction script of software package in rpm and deb format, to improve the application flexibility of such software package on Linux operating system.

Description

[0001] This application is a divisional application. The original application has the application number 202411181175.7 and the original application date is August 26, 2024. The entire contents of the original application 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 PackageMagnager (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, for two different packages with the same name, these two packages 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: 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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.

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

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

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

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] Fifthly, a computing device cluster is provided, including at least one computing device, each computing device including a processor and memory; 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.

[0049] 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.

[0050] 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.

[0051] 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

[0052] Figure 1 This is a schematic diagram of the architecture of a system for building software packages provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of another system for building software packages provided in this application embodiment; Figure 3 This is a schematic diagram of the architecture of another system for building software packages provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application; Figure 5 This is a flowchart of a method for constructing a software package provided in an embodiment of this application; Figure 6 This is a diagram illustrating a software package installed on an operating system. Figure 7 This is a schematic diagram illustrating a scenario where hash values ​​are calculated for multiple building elements of a first software package, as provided in an embodiment of this application. Figure 8 This is a schematic diagram illustrating a scenario where a second build script is obtained by modifying a first build script, as provided in an embodiment of this application. Figure 9 This is a schematic diagram of an SBOM provided in an embodiment of this application; Figure 10 This is a flowchart of a method for managing software packages provided in an embodiment of this application; Figure 11 This is a schematic diagram of a multi-user environment provided in an embodiment of this application; Figure 12 This is a schematic diagram illustrating the overall process of building and installing a software package according to an embodiment of this application; Figure 13 This is a schematic diagram of the structure of an apparatus for building software packages provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of a management software package device provided in an embodiment of this application. Detailed Implementation

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

[0054] 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.

[0055] 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.

[0056] 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.

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

[0058] 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 these rpm or deb packages, the installation path on the Linux operating system is pre-defined, such as ` / usr / bin / xxx`, where `xxx` is the name of a file within the package. Thus, 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.

[0059] 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.

[0060] 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.

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

[0062] 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.

[0063] (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 in the operating system. The directories in the directory 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.

[0064] 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.

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

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

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

[0072] 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.

[0073] The build subsystem 1 can reuse resources from existing software package build technologies, such as those from rpm or deb 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 new format software package. 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 packages. Further details will follow. Figure 2 The embodiments shown are described in detail below.

[0074] The following is about Figure 1 The functions of each subsystem are explained below.

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

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

[0077] like Figure 2As shown, 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.

[0078] 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.

[0079] 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.

[0080] 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 the technology of building RPM format software packages, the generated build script is a first type of build script, and an example of a first type of build script is a spec file. As another example, when the package addition tool is used in the technology of building DEB format software packages, the generated build script is a second type of build script, and an example of a second type of build script is a control file and a rules file.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] It should be noted that, Figure 2 This is an example structure of the building module 15. The internal modules of the building module 15 are not limited in this application embodiment. When applying the application embodiment, the building module 15 may include more or fewer modules, which will not be described in detail here.

[0085] 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.

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

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] In addition, such as Figure 2 As shown, 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 follow. Figure 5 The following is a detailed description of the embodiments.

[0092] pass Figure 2 The build subsystem 1 shown 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 then a first software package in a new format is generated based on the second build script.

[0093] The implementation method of reusing resources from existing software package building technologies to obtain the first build script can be referenced. Figure 5 The relevant embodiments will not be described in detail here.

[0094] 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.

[0095] 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.

[0096] After building the first software package, the build module 15 stores it in the software repository management subsystem 2. For example... Figure 2 As shown, the software repository management subsystem, for example, stores two software packages with the same name but different build elements, labeled 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.

[0097] In addition, such as Figure 2 As shown, 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.

[0098] It should be noted that, Figure 2 This 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 described in detail here.

[0099] 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 follow. Figure 10 The embodiments shown are described in detail below.

[0100] 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 into the user environment during the runtime 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 follow. Figure 10 The embodiments shown are described in detail below.

[0101] 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 will follow. Figure 10 The embodiments shown are described in detail below.

[0102] 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.

[0103] Additionally, 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. Figure 2 (These modules are not shown in the diagram), and the functions of these modules are not described in detail in the embodiments of this application.

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

[0105] Figure 3 This is a schematic diagram of the architecture of another system for building software packages provided in this application embodiment. For example... Figure 3 As shown, the system includes a development end and a user end. The development end includes at least one computer device for implementing... Figure 1 and Figure 2 The functionality of subsystem 1 is constructed within the framework. The user terminal includes at least one computer device for implementing... Figure 1 and Figure 2 The functions of package management subsystem 3 are shown.

[0106] 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.

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

[0108] Figure 4 This 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... Figure 3 The developer or user interface shown. For example... Figure 4 As shown, the computer device includes at least one processor 401, a communication bus 402, a memory 403, and at least one communication interface 404.

[0109] 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.

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

[0111] 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 electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, 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 not limited thereto. The memory 403 may exist independently and be connected to the processor 401 via the communication bus 402. The memory 403 may also be integrated with the processor 401.

[0112] 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.

[0113] 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.

[0114] In a specific implementation, as one example, a computer device may include multiple processors, for example... Figure 4 The processors 401 and 405 are shown. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0115] 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.

[0116] 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 digital assistant (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.

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

[0118] Figure 5 This is a flowchart illustrating a method for building a software package according to an embodiment of this application. This method is exemplarily applied to… Figure 3 The build subsystem in the development environment is shown. For example... Figure 5 As shown, the method for building the software package includes the following steps.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

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

[0124] 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.

[0125] For example, such as Figure 2As shown, 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.

[0126] 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.

[0127] For example, such as Figure 2 As shown, if the software artifact repository already contains the software artifact for the first software package to be built, the software specification module can directly obtain the software artifact for the first software package from the software artifact repository. This software artifact includes the source code package and the build script. The build script is then 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.

[0128] 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.

[0129] 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.

[0130] For example, such as Figure 2 As shown, 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 corresponding build script for the second software package, and obtain the first build script.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] For example, suppose that 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, and the second build script obtained through step 502 includes second installation paths corresponding to these 10 files.

[0137] 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.

[0138] 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.

[0139] Figure 6 This is a diagram illustrating a software package in RPM or DEB format installed on an operating system. (Example) Figure 6 As shown, if package B depends on package D version 1.1, and package C depends on package D version 1.2, assuming these packages are both in RPM or DEB format, because package D versions 1.1 and 1.2 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 package D version 1.1, then package B and package C can be installed on the same operating system. Alternatively, if both package B and package C depend on package D version 1.2, then package B and package C can also be installed on the same operating system.

[0140] 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.

[0141] 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.

[0142] 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 security vulnerabilities, such as common vulnerabilities and exposures (CVEs), both packages need to be rebuilt to update them. In contrast, with RPM or DEB packages, 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.

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

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

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

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] 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.

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

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

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

[0166] Figure 7 This is a schematic diagram illustrating a scenario where hash values ​​are calculated for multiple building elements of a first software package, as provided in an embodiment of this application. It should be noted that... Figure 7 The multiple building elements in the example are used to illustrate how to calculate the hash value. This application does not limit the number or type of the multiple building elements used to calculate the hash value.

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

[0168] like Figure 7 As shown, the steps for calculating the hash values ​​of multiple build elements include: calculating the hash value of the package itself using methods such as hash256 or hash512, the result of which is labeled as the package hash; calculating the hash value of dependent packages, the result of which is labeled as the dependency hash; and calculating the hash value of the package's runtime environment, the result of which is labeled as the env hash. Figure 7 (not shown in the image), these three hash values ​​are further used to calculate a total hash value, which is then used as the hash value of these multiple building elements, that is, the building element identifier of these multiple building elements.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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.

[0173] Taking a spec file as an example, the macros included in the first build script are as follows: _prefix: / usr _sysconfdir: / etc _sbindir: / sbin _bindir: / bin An example of a macro expanded in the above manner is shown below: _prefix: %{_epkg_prefix} / usr _sysconfdir: %{_epkg_prefix} / etc _sbindir: %{_exec_prefix} / sbin _bindir: %{_exec_prefix} / bin Among them, `_epkg_prefix` and `_exec_prefix` include the build element identifiers calculated using the aforementioned reference algorithm. Thus, the paths in the paragraphs beginning with `%install` in the build script are exemplified as follows: Figure 8 As shown, the installation path is redirected from the first installation path to the second installation path.

[0174] In addition, such as Figure 8As shown, 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.

[0175] In addition, such as Figure 8 As shown, the spec file can also include paragraphs starting with %pre and %post. The information following %pre indicates the storage path of scripts that need to be executed before installing the first package, and the information following %post indicates the storage path of scripts that need to be executed after installing the first package. Figure 8 As shown on the left, the storage paths for these scripts are typically fixed. In this embodiment, the scripts indicated in paragraphs beginning with %pre are referred to as pre-installation execution scripts, and the scripts indicated in paragraphs beginning with %post are referred to as post-installation execution scripts. Figure 8 The storage paths for scripts in paragraphs starting with %pre and %post in the spec file on the left are referred to as the default script storage paths.

[0176] In this embodiment of the application, to further improve the application flexibility of pre-installation and post-installation script execution, the default script storage paths can be redirected, such as... Figure 8 As shown in the spec file on the right, a second extended directory is added above the default script storage path. This second extended directory is related to the code in the scripts executed before and after installation.

[0177] 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.

[0178] 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.

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

[0180] Alternatively, the default script storage path for pre-installation and post-installation scripts can be left unchanged instead of redirecting it. Figure 8 The default script storage path in the spec file on the left. In this scenario, since these scripts are already installed in the operating system's user environment before the first software package is installed, they can be stored in a transparent container. Figure 8 The default script storage path in the spec file on the left is mounted to the operating system's user environment so that these scripts can be found directly in the user environment.

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

[0182] 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.

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] Figure 9 This 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 an element, and the value of that element is to the right of the right arrow symbol. Figure 9This example uses the SBOM format as the system package data exchange (SPDX) format for illustration, but the embodiments of this application are not limited to the SBOM format.

[0199] 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.

[0200] like Figure 9 As shown, the SBOM not only records 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 records 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.

[0201] In this embodiment of the application, the values ​​of certain elements in the SBOM can be determined based on the hash value of the corresponding element, so that the corresponding element can be accurately found based on the value. For example... Figure 9 As shown, 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 build elements in step 502, or it can be different, as long as current_package_hash can uniquely identify the first package.

[0202] about Figure 9 For descriptions of other fields, please refer to the relevant SPDX standards; examples will not be provided here.

[0203] After obtaining the first completed software package through steps 501 to 503, it can be... Figure 1 The software repository management subsystem shown stores the first software package so that users can download and install it later through the package management subsystem.

[0204] 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.

[0205] 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.

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

[0207] Figure 10 This application provides a method for managing software packages. The method is exemplarily applied to… Figure 3 The packet management subsystem in the client shown is illustrated. Figure 10 As shown, the method includes the following steps.

[0208] 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.

[0209] 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.

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

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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.

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

[0216] 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.

[0217] 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.

[0218] 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.

[0219] Figure 11 This is a schematic diagram of a multi-user environment provided in an embodiment of this application. For example... Figure 11 As shown, assuming there are user environment 1 and user environment 2 created in the operating system, in user environment 1, a symbolic link is created between the first path and the second installation path 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 symbolic link is created between the first path and the second installation path so that users in user environment 2 can run the first software package through the first path in user environment 2.

[0220] 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.

[0221] like Figure 11As shown, 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.

[0222] 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 based on that path. For example... Figure 11 As shown, the operating system is configured with a dynamic link library, which contains two dependency packages of the first software package. The installation paths of these two dependency packages are $hash-glibc-$ver / lib / lib.so.6 and $hash-glibc-$ver / lib / libpthread.so.0, respectively.

[0223] The following is based on Figure 12 For example Figure 5 and Figure 10 The embodiments shown will be described in their entirety. It should be noted that... Figure 12 Used to illustrate embodiments of this application. Figure 12 Regarding the aforementioned Figure 5 as well as Figure 10 The embodiments shown are not intended to be limiting.

[0224] like Figure 12 As shown, 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.

[0225] 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. For example... Figure 12 As shown, the installation path of each file includes a first extension directory " / opt / epkg / $hash-glibc-3.x", and "$hash" in the first extension directory is the hash value of multiple build elements of the first package.

[0226] 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.

[0227] 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.

[0228] 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.

[0229] 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.

[0230] 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.

[0231] 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.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

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

[0241] In addition, based on Figure 5 As shown in the illustrated embodiment, the first software package may also include a Software Bill of Materials (SBOM) or SBOM tags, whereby the SBOM records 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 security vulnerabilities in the first software package based on the SBOM or SBOM tags.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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.

[0246] 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.

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

[0248] 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.

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

[0250] Module 1301 is used to 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. For detailed implementation details, please refer to [link / reference]. Figure 5 Step 501 in the embodiment.

[0251] 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 indicates the installation location of the target files and is related to multiple build elements of the first software package. For detailed implementation, please refer to [reference needed]. Figure 5 Step 502 in the embodiment.

[0252] Module 1303 is used to build a first software package based on a second build script. The first software package contains a second installation path. For detailed implementation instructions, please refer to [link / reference needed]. Figure 5 Step 503 in the embodiment.

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

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

[0255] 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.

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

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

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

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] 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.

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

[0265] 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 indicate the installation location of target files. The target files are files 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 details, please refer to [reference needed]. Figure 10 Step 1001 in the embodiment.

[0266] Module 1402 is used to install and run the first software package according to the second installation path. For detailed implementation instructions, please refer to [link / reference needed]. Figure 10 Step 1002 in the embodiment.

[0267] 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.

[0268] 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.

[0269] 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.

[0270] 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.

[0271] 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; The determination module is used to determine the security vulnerabilities of the first software package based on the SBOM or the SBOM's tags.

[0272] 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.

[0273] 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 website, computer, server, or data center 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)).

[0274] 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.

[0275] 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, which is used to build 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 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 second installation path is related to multiple build elements of the first software package. The first software package is built based on a second build script. The second build script 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 target files. The target files are files compiled during the process of building 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. 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.

27. The apparatus as claimed in claim 26, 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.

28. The apparatus as claimed in claim 27, 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.

29. The apparatus according to any one of claims 26-28, 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.

30. The apparatus according to any one of claims 26-29, 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.

31. 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.

Images