Software package construction method and device, computer device, readable storage medium and program product

Abstract

The application relates to a software package construction method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: obtaining an original software package belonging to a compiled executable original distribution; the original software package comprises sub-packs and corresponding software package description files; determining a main pack of the original software package from the sub-packs, and taking the remaining sub-packs except the main pack in the sub-packs as target sub-packs relative to the main pack; modifying the software package description files corresponding to the target sub-packs to obtain sub-software package description files; merging the sub-software package description files into the software package description files corresponding to the main pack to obtain target software package description files; and constructing a temporary directory according to the sub-packs, and obtaining a target software package belonging to a compiled executable target distribution corresponding to a target construction environment according to the target software package description files, the temporary directory and the target construction environment. The method can improve the construction efficiency of the target software package.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, and in particular, to a software package construction method and device, computer equipment, computer readable storage medium, and computer program product. BACKGROUND

[0002] RPM (Red Hat Package Manager) is a kind of software package manager. For RPM software package adaptation, the adaptation problem in the construction process is usually solved by constructing a source code package, so as to obtain a software package belonging to a compiled executable. However, this method requires obtaining the corresponding source code package, and when the business needs to be migrated and adapted, it is usually because there is a specific version (i.e., a target distribution) requirement for some components, and the source code package of the specific version may no longer be open source. In the case where the source code package is difficult to obtain, the existing solution is to search for the source code, start compiling from the source code, and at the same time, compare with other distribution software packages belonging to compiled executables, and reversely construct the target distribution software package belonging to the compiled executable. This method is inefficient. SUMMARY

[0003] Therefore, it is necessary to provide a software package construction method, device, computer equipment, computer readable storage medium, and computer program product to improve the construction efficiency of the target distribution software package belonging to the compiled executable.

[0004] In a first aspect, the present application provides a software package construction method, comprising:

[0005] obtaining an original software package belonging to a compiled executable of an original distribution; the original software package comprising sub-packages and software package description files corresponding to the sub-packages;

[0006] determining a main package of the original software package from the sub-packages, and taking the remaining sub-packages in the sub-packages other than the main package as target sub-packages relative to the main package;

[0007] modifying the software package description files corresponding to the target sub-packages to obtain sub-software package description files;

[0008] merging the sub-software package description files into the software package description files corresponding to the main package in the original software package to obtain target software package description files;

[0009] constructing a temporary directory according to the sub-packages, and obtaining a target software package belonging to a compiled executable of a target distribution corresponding to the target construction environment based on the target software package description files, the temporary directory, and the target construction environment.

[0010] In one embodiment, modifying the software package description files corresponding to the target sub-packages to obtain the sub-software package description files comprises:

[0011] obtaining a base name corresponding to the target sub-package;

[0012] determining the package names of each stage in the software package description file corresponding to the target sub-package based on the packaging mechanism and the base name corresponding to the original software package;

[0013] updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package respectively to obtain a sub-software package description file.

[0014] In one embodiment, updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package respectively to obtain a sub-software package description file comprises:

[0015] updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package respectively according to the stages to which the package names belong to, to obtain an intermediate description file;

[0016] adding a first instruction for disabling automatic generation of runtime dependencies in the intermediate description file to avoid automatically generated incorrect runtime dependencies caused by different software package construction environments, to obtain a sub-software package description file.

[0017] In one embodiment, determining the main package of the original software package from the sub-packages comprises:

[0018] obtaining source code package name information corresponding to the original software package;

[0019] determining the main package of the original software package from the sub-packages according to the source code package name information.

[0020] In one embodiment, constructing a temporary directory according to the sub-package comprises:

[0021] constructing an initial directory;

[0022] converting the sub-package into an archive file and decompressing the archive file into the initial directory to obtain a temporary directory.

[0023] In one embodiment, obtaining the target software package corresponding to the target distribution of the target construction environment comprises:

[0024] determining the target construction environment and determining the packaging order in the target software package description file;

[0025] packaging the sub-packages in the temporary directory based on the packaging order to obtain the target software package corresponding to the target distribution of the target construction environment.

[0026] In a second aspect, the present application provides a software package construction apparatus, comprising:

[0027] an acquisition module configured to acquire a raw software package belonging to a post-compilation executable raw software package of a raw distribution;

[0028] a correction module configured to determine a main package of the raw software package from the sub-packages, and take the remaining sub-packages other than the main package as target sub-packages relative to the main package; correct the software package description files corresponding to the target sub-packages to obtain sub-software package description files; and merge the sub-software package description files into the software package description file corresponding to the main package in the raw software package to obtain a target software package description file;

[0029] a construction module configured to construct a temporary directory according to the sub-packages, and obtain a target software package belonging to a post-compilation executable target software package of a target distribution corresponding to a target construction environment based on the target software package description file, the temporary directory and the target construction environment.

[0030] In a third aspect, the present application provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method of the first aspect when executing the computer program.

[0031] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program, and the computer program implements the steps of the method of the first aspect when executed by a processor.

[0032] In a fifth aspect, the present application provides a computer program product, comprising a computer program, and the computer program implements the steps of the method of the first aspect when executed by a processor.

[0033] The software package construction method, apparatus, computer device, computer readable storage medium and computer program product, based on the raw software package belonging to the post-compilation executable raw software package of the raw distribution, correct the software package description files of the target sub-packages in the raw software package and merge them into the software package description file corresponding to the main package to obtain the target software package description file, which realizes the automation of the software package description file correction, and then construct the temporary directory according to the sub-packages, and obtain the target software package belonging to the post-compilation executable target software package of the target distribution corresponding to the target construction environment based on the target software package description file, the temporary directory and the target construction environment, thereby improving the construction processing efficiency of the software package. BRIEF DESCRIPTION OF DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application or the related art. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained from these drawings without creative labor.

[0035] Figure 1 The first flowchart of the software package construction method in an embodiment is shown in FIG. 1.

[0036] Figure 2 The second flowchart of the software package construction method in an embodiment is shown in FIG. 2.

[0037] Figure 3 The third flowchart of the software package construction method in an embodiment is shown in FIG. 3.

[0038] Figure 4 The fourth flowchart of the software package construction method in an embodiment is shown in FIG. 4.

[0039] Figure 5 The fifth flowchart of the software package construction method in an embodiment is shown in FIG. 5.

[0040] Figure 6 The structure block diagram of the software package construction apparatus in an embodiment is shown in FIG. 6.

[0041] Figure 7 The internal structure diagram of the computer device in an embodiment is shown in FIG. 7. DETAILED DESCRIPTION

[0042] In order to make the purposes, technical solutions and advantages of the present application more clear, the following will further describe the present application in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application.

[0043] The following will first describe the terms related to the technical solutions of the present application:

[0044] RPM (Red Hat Package Manager) is a software package manager used in Red Hat-based Linux, which is used to manage the installation, update, query and uninstall of software packages. Accordingly, the RPM file, i.e. rpm file, is usually a file ending with.rpm.

[0045] YUM (Yellowdog Updater, Modified) is a software package manager built on RPM.

[0046] RPMbuild, a command-line tool for building RPM software packages.

[0047] RPMrebuild, a tool for rebuilding RPM packages.

[0048] RPM itself can represent a management approach, and unlike YUM, it is mainly used as an offline management method, but RPM and YUM are essentially operations on files ending in.rpm. For both Red Hat-based distributions, in the case of source RPM, you can use the source src.rpm package (source code RPM package) to build a binary RPM package using RPMbuild to enhance the user mode (User Mode) capabilities of the distribution and expand system components to meet various business needs.

[0049] Source code src.rpm package, which supports custom compilation of software, such as adding specific functions, applying performance optimization, or fixing bugs. Users can modify the.spec file or source code to adjust the behavior of the software, and then use RPMbuild to generate a new binary RPM package.

[0050] Binary RPM package, which is prepared for end users, users do not need to care about how the software is compiled, they only need to simply use the package manager to install the software. Binary RPM package simplifies the software deployment process, allowing users to quickly install and update software. Binary RPM package is a compiled executable software package.

[0051] SPEC, also known as spec, spec file, SPEC file, software package description file, is used to define how to build a software package from source code, install software, and generate the final RPM package. The SPEC file contains all instructions and information for the build and installation process, ensuring that the software can be correctly compiled, installed, and run on the target system. Spec is the most core part of making RPM packages.

[0052] SPEC file is used to define how to build RPM package, it can contain multiple parts or stages, each stage has its specific purpose. Exemplarily, the following are the main stages of a SPEC file:

[0053] Preamble (Preamble): This part is not strictly a "stage", but it contains some basic information such as package name, version, release number, summary, license, etc. This information is usually at the top of the file.

[0054] %description (Description): Provides a detailed description of the package. This helps users understand the functions and purposes of the package.

[0055] %prep (prepare): During this phase, the source code is prepared for compilation. This typically involves unpacking the source archive and applying any necessary patches. The %setup macro is often used for this purpose; by default, it unpacks the source code and enters the unpacked directory.

[0056] %build (build): Performs the actual compilation work. This stage executes all necessary commands to compile the source code and generate binary files or other outputs.

[0057] %install: Installs the compiled files into a temporary directory that simulates the layout of the final system. Use the %{buildroot} variable to specify the target path.

[0058] %check: This is optional and is used to run the test suite to verify that the software was built correctly. Not all SPEC files include this section.

[0059] %clean: Cleans up after the build is complete, deleting temporary files and directories. This is particularly useful for ensuring a clean build environment.

[0060] %files (file list): Lists all the files that will be included in the RPM package, and can specify permissions and other attributes for these files. This section also allows the specification of special types of files such as configuration files.

[0061] %changelog (change log): records the history of changes to the package. Each change typically includes a version number, release number, date, and a brief description of the change.

[0062] In addition, several script sections can be defined in the SPEC file. These sections are executed at different points during package installation or uninstallation: %pre: executed before the package is installed; %post: executed after the package is installed; %preun: executed before the package is uninstalled; and %postun: executed after the package is uninstalled. These different sections and stages work together to ensure that the software is packaged, distributed, installed, and uninstalled correctly.

[0063] JAR file (Java Archive, also known as jar package), a software package file format, is commonly used to aggregate a large number of Java class files, related metadata and resource (text, images, etc.) files into one file for the development of Java platform application software or libraries.

[0064] Buildroot, also known as BUILDROOT, is an open source build system tool used to generate the root file system, Linux kernel, device drivers, and applications of embedded Linux systems.

[0065] The rpm2cpio command is a tool used to convert RPM packages to cpio format in Linux. Through this conversion, users can more easily view and extract files from RPM packages.

[0066] Grep and awk are two widely used command-line tools in Unix / Linux systems, primarily for text processing. The grep command searches for matching lines in a file and displays them. Awk can perform complex operations on text, such as formatting and filtering.

[0067] BuildArch, a directive in the .spec file in RPM packaging, is used to specify the system architecture that the software package should target during the build process.

[0068] AutoReq: no, a directive in the .spec file in RPM packaging that controls the automatic generation of requirements for software package dependencies.

[0069] The pipe symbol (|) is used for inter-process communication. It allows the output of one command to be directly used as the input of another command, thereby achieving efficient transmission and processing of data streams.

[0070] cpio, a tool for creating and extracting file archives.

[0071] The cpio-idvm command is used to extract files from a cpio archive file and restore them to the file system.

[0072] RPM-ivh, a command for installing RPM packages.

[0073] RPM-qp--qf "%{SourceRPM}" <rpm-package>, which is used to query the specified RPM package and display only the source RPM (SRPM) name corresponding to the package through formatted output.

[0074] After the above description, the technical solution of this application is described below:

[0075] When adapting packages missing from the current distribution, the common approach is to build the source code package, resolving any adaptation issues during the build process and ultimately obtaining a runnable binary RPM package. However, this approach has drawbacks when adapting large components: it requires the component's open-source source RPM package. Business migration and adaptation often require specific versions of certain components, and the source RPM packages for these specific versions are likely no longer open-source. For example, for the Hadoop 2.5 series, these RPM components primarily consist of cross-platform JAR packages, including but not limited to JAR packages, various script files, front-end frameworks, and desktop development frameworks. When the source code package is difficult to obtain, the only option is to locate the source code, compile it step by step, and then compare it to the binary RPM packages of other distributions, referencing the file lists or spec files provided, and gradually improve the spec files for this version to reverse engineer the binary package. Clearly, this approach is costly and error-prone.

[0076] Based on the above analysis, this application addresses the challenges of adapting large component software packages and proposes a software package construction method. This method directly processes and analyzes the original, compiled, executable software package of the original release through reverse engineering, modifies the software package description file, and then repackages it to obtain the target, compiled, executable software package of the target release. This method improves efficiency. The following examples illustrate this method:

[0077] In one embodiment, Figure 1 As shown, the present application provides a method for building a software package. This embodiment uses the method applied to a computer device as an example, and the computer device can be installed with a Linux system. It can be understood that the computer device to which the method is applied can be a computer device corresponding to a server or a computer device corresponding to a terminal device. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. In some embodiments, the application scenarios of the technical solution of the present application can be scenarios such as software development and testing. The method can include steps S101 to S105, as follows:

[0078] Step S101: The computer device acquires a compiled executable original software package belonging to an original distribution.

[0079] The original software package can be a software package of an original distribution corresponding to an original construction environment or an original system environment. The original software package can be acquired, for example, the original software package can be installed on one or more devices and thus can be directly acquired; for another example, the original software package can be directly downloaded from one or more websites.

[0080] In some embodiments, the original software package can be a binary RPM package.

[0081] In some embodiments, the source code package corresponding to the original software package can be open source or non-open source.

[0082] The sub-packet can be for the original software package, i.e., the sub-packet is a sub-packet of the original software package.

[0083] In some embodiments, the original software package can include at least two sub-packets.

[0084] In some embodiments, the computer device can extract the software package description file (spec) of each sub-packet from the original software package. Since the spec at this time is only used for a single sub-packet, if the spec is directly used, the source code package information of the constructed software package is the package itself, rather than for the entire original software package, and thus the sub-packet spec information needs to be corrected and the specs need to be combined.

[0085] Step S102: The computer device determines the main packet of the original software package from the sub-packets, and takes the remaining sub-packets other than the main packet as target sub-packets relative to the main packet.

[0086] The target sub-packet can be for the main packet.

[0087] Exemplarily, the logical relationship among the original software package, the sub-packet, the main packet, and the target sub-packet can be represented as follows:

[0088] The original software package = n sub-packets = 1 main packet + (n-1) target sub-packets, where n represents the number of sub-packets in the original software package.

[0089] In some embodiments, the computer device can determine the main package of the original software package based on the dependency relationship between the sub-packages. For example, the main package can be a package that is depended by multiple sub-packages. For example, there are three sub-packages in the original software package, sub-package a, sub-package b and sub-package c. Sub-package a depends on sub-package b and sub-package c. Sub-package c depends on sub-package b. The running of sub-package b does not depend on sub-package a and c. Therefore, sub-package b can be determined as the main package of the original software package.

[0090] In some embodiments, the computer device can view the information of the original software package based on the command line tool, so as to determine which is the main package.

[0091] Step S103: The computer device corrects the software package description file corresponding to the target sub-package to obtain a sub-software package description file.

[0092] In some embodiments, the computer device can correct the package name of each stage in the software package description file corresponding to the target sub-package. The correction can be at least one of adding the package name, modifying the package name, deleting the package name, etc. In some embodiments, in addition to the correction of the package name, the correction of the dependency relationship can also be involved.

[0093] In some embodiments, the computer device can determine the software package description file corresponding to the main package from the software package description file corresponding to the sub-package, as the main software package description file. Therefore, the software package description file other than the main software package description file can be directly corrected.

[0094] In some embodiments, the computer device can correct the software package description file corresponding to the target sub-package according to the main software package description file. For example, the naming form between the main package and the target sub-package can be unified. For example, the name of the main package is A, and the name of the target sub-package can be A1, A2 and A3, etc. Therefore, confusion can be avoided.

[0095] Step S104: The computer device merges the sub-software package description file into the software package description file corresponding to the main package of the original software package to obtain a target software package description file.

[0096] In some embodiments, the computer device can merge the sub-software package description file into the software package description file corresponding to the main package of the original software package based on the order of each stage in the software package description file.

[0097] For example, the contents related to package (used to define a sub), files (list all the files to be packaged into the software package and their destination path), description (provide the description information of the software package), pre, post, etc. are merged.

[0098] Step S105: The computer device constructs a temporary directory according to the sub-package, and obtains a compiled and executable target software package of the target release corresponding to the target build environment based on the target software package description file, the temporary directory and the target build environment.

[0099] The target build environment may be a build environment that has a package adaptation requirement for the original software package, such as a Linux system environment of a specific version. In the target build environment, there is a lack of a version corresponding to the original software package, that is, a target distribution.

[0100] The target software package and the original software package may be identical in function or purpose, but different in applicable build environment or system environment, that is, they belong to different versions of software packages.

[0101] In some embodiments, the source code package corresponding to the target software package may be non-open source, or may have been open source in the past but is no longer open source.

[0102] The above technical solution, based on the original software package of the original release version that is executable after compilation, obtains the target software package description file by correcting the software package description file of the target sub-package in the original software package and merging it into the software package description file corresponding to the main package. This realizes the automation of software package description file correction, thereby helping to improve the efficiency of software package construction and ensure the stability of the target software package constructed based on the target software package description file. A temporary directory is constructed based on the sub-package, and based on the target software package description file, the temporary directory and the target build environment, a target software package corresponding to the target release version that is executable after compilation is obtained. On the basis of improving the efficiency of software package construction, this also realizes that the target software package can be constructed without source code packages, source code, etc., breaking the dependence on source code packages, source code, etc., and providing a new approach for the adaptation of non-open source software.

[0103] In one embodiment, the aforementioned "modifying the software package description file corresponding to the target sub-package to obtain the sub-software package description file" may include: the computer device obtaining a base name corresponding to the target sub-package; determining, based on the packaging mechanism and base name corresponding to the original software package, the package names of each stage in the software package description file corresponding to the target sub-package; and updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package, thereby obtaining the sub-software package description file.

[0104] Here, update can be understood in a broad sense, which may include at least one of operations such as deletion, addition, and replacement.

[0105] In some embodiments, the base name may be the actual software name of the target sub-package, that is, the name defined by "Name" in the software package description file corresponding to the target sub-package.

[0106] In some embodiments, the computer device may search and obtain the base name corresponding to the target sub-package through a preset command line tool, such as grep and awk, to improve the efficiency of obtaining the base name.

[0107] In some embodiments, the packaging mechanism may be a packaging mechanism of an RPM software package.

[0108] In some embodiments, the computer device can determine the package names of each stage in the software package description file corresponding to the target sub-package based on the packaging mechanism of the spec and rpm package and combine the base name and add them, thereby clearly indicating the package names of each stage to ensure that each RPM contains its own correct content when the software package is rebuilt.

[0109] In some embodiments, the computer device can sub-package the spec by deleting the line starting with Name in the spec corresponding to the target sub-package and replacing it with %package -n bin_nameA before the "BuildArch" line, that is, by modifying the spec of the target sub-package, it actually becomes a "sub-package" of the main package.

[0110] The above technical solution is aimed at the target sub-package of the main package. Based on the packaging mechanism corresponding to the original software package and the base name corresponding to the target sub-package, the package name of each stage in the software package description file corresponding to the target sub-package is determined and added, ensuring that the package name of each stage in the software package description file corresponding to the target sub-package is clearly pointed out, thereby ensuring that the target sub-package contains its own correct content when the software package is rebuilt.

[0111] In one embodiment, the aforementioned "updating the package names at each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package, thereby obtaining the sub-package description file" may include: the computer device updating the package names at each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package, according to the stages to which the package names correspond, thereby obtaining an intermediate description file. A first instruction for disabling automatic generation of runtime dependencies is added to the intermediate description file to avoid automatically generating erroneous runtime dependencies due to differences in software package build environments, thereby obtaining the sub-package description file.

[0112] Runtime dependencies refer to additional packages or libraries that software requires during execution. These dependencies are essential components for the software to function properly and may include shared libraries, system tools, or other services. Unlike compile-time dependencies, runtime dependencies focus on the actual requirements of the software when it is running on the target machine.

[0113] Herein, incorrect runtime dependencies can be understood in a broad sense, which may include inaccurate or unnecessary runtime dependencies.

[0114] In some embodiments, the software package build environment corresponding to the computer device is the target build environment, the software package build environment corresponding to the original software package is the original build environment, and the target build environment is different from the original build environment.

[0115] In some embodiments, both the target software package and the original source package are binary RPM packages. During the process of building the target software package, the RPM package mechanism automatically scans the build environment for information, such as shared objects (.so) files, and adds them to the runtime dependencies of the software package. To address this, a first instruction for disabling automatic generation of runtime dependencies can be added to the intermediate description file to avoid automatically generating incorrect runtime dependencies due to differences in the software package build environment.

[0116] In some embodiments, the first instruction may be AutoReq: no, which may be added after the "%package" line in the sepc corresponding to the target sub-package.

[0117] In addition to clearly indicating the package names at each stage in the software package description file corresponding to the target sub-package, the above technical solution also disables the automatic generation of runtime dependencies by adding a first instruction in the intermediate description file. This can avoid the automatic generation of incorrect runtime dependencies due to different software package build environments, thereby ensuring the accuracy of the obtained sub-package description file.

[0118] In one embodiment, Figure 2 As shown, the aforementioned "determining the main package of the original software package from each sub-package" may include steps S201 to S202:

[0119] Step S201: The computer device obtains the source code package name information corresponding to the original software package.

[0120] In some embodiments, the computer device can obtain the source package name information corresponding to the original software package based on a preset command line tool, such as rpm -q --qf '%{SourceRPM}\n'<package_name> Order.

[0121] In some embodiments, the computer device may obtain the source code package name information corresponding to the original software package based on an analysis of a software package description file corresponding to the original software package.

[0122] Step S202: The computer device determines the main package of the original software package from each sub-package according to the source code package name information.

[0123] In some embodiments, the base name of the source package name corresponding to the original software package is the same as the base name of the main package. Therefore, the sub-package with the same base name as the source package name corresponding to the original software package in the source package name information can be found from each sub-package, thereby determining the main package of the original software package.

[0124] In some embodiments, the source package name information provides basic information about the original software package (name, version, and release), and the name of the original software package's main package may include this basic information as well as a system architecture identifier, such as x86_64. Based on the source package name information and the system architecture identifier, the computer device can identify the main package of the original software package from among the sub-packages. For example, from the sub-package names corresponding to each sub-package, the computer device can identify the sub-package name that only includes the source package name information and the system architecture identifier as the main package name, thereby determining the main package of the original software package.

[0125] The above technical solution determines the main package of the original software package from each sub-package based on the source package name information, distinguishes the main package in the original software package and the target sub-package of the main package, thereby helping to ensure the accuracy of subsequent revisions to the software package description file corresponding to the target sub-package.

[0126] In one embodiment, the aforementioned "building a temporary directory according to the sub-package" may include: building an initial directory; converting the sub-package into an archive file, and decompressing the archive file into the initial directory to obtain a temporary directory.

[0127] In some embodiments, the initial directory and the temporary directory may be the root directory.

[0128] In some embodiments, the computer device may archive all sub-packages of the original software package, including the main package and the target sub-package, and decompress them into the initial directory to obtain a temporary directory. For example, the computer device may convert each sub-package into an archive format using a command line tool, such as rpm2cpio, and pass the files to the cpio -idvm command via a pipe symbol to decompress the contents of the packages into the initial directory, thereby generating directories such as . / etc and . / usr in the initial directory and the files therein, thereby obtaining a temporary directory.

[0129] The above technical solution constructs an initial directory to archive and decompress the sub-packages of the original software package to obtain a temporary directory, thereby preparing the files to be packaged, serving the subsequent steps of packaging according to the target software package description file, building the target software package, and other related steps.

[0130] In one embodiment, the aforementioned "obtaining, based on the target software package description file, the temporary directory, and the target build environment, a target software package that corresponds to the target release version of the target build environment and is executable after compilation" may include: the computer device determining the target build environment and determining the packaging order in the target software package description file; and packaging the sub-packages in the temporary directory based on the packaging order to obtain the target software package that corresponds to the target release version of the target build environment and is executable after compilation.

[0131] In some embodiments, the computer device can identify its own system architecture and determine the target build environment based on its own system architecture.

[0132] In some embodiments, the computer device may package the prepared sub-packages (main package and target sub-package) files in the temporary directory based on the packaging order in the target software package description file, thereby obtaining the target software package.

[0133] In some embodiments, the computer device can build the target software package in a clean, isolated environment, thereby ensuring that the target software package description file can work properly under different system configurations.

[0134] In some embodiments, the computer device may check the packaging order in the target software package description file, for example, based on preset rules or pre-trained models, to check whether the packaging order is correct, for example, the compilation phase should be before the testing phase in the packaging order.

[0135] In some embodiments, the packaging order can be to complete all definitions of the main package first (including %prep, %build, %install, and %files), and then define the specific information of each sub-package in turn. This not only helps maintain and understand the .spec file, but also ensures that all dependencies and operations are executed as expected. In this way, complex multi-package projects can be effectively managed.

[0136] The above technical solution packages the sub-packages in the temporary directory based on the packaging order in the target package description file, thereby obtaining a compiled and executable target package for the target build environment and the target distribution. This helps improve the target package build efficiency and ensures the accuracy of the built target package.

[0137] In one embodiment, as shown in the attached Figure 3 As shown, a method for building a software package is provided. The method can be divided into a decomposition stage and a packaging stage. The method can include steps S301 to S306, which are specifically as follows:

[0138] The contents of steps S301 to S303 correspond to the extraction and correction of RPM package information, i.e. the decomposition stage, as shown in the attached Figure 4 As shown in the figure, the corresponding principle is given, specifically:

[0139] Step S301: Prepare the RPM software package and installation tool software package. Download the binary RPM packages (i.e., the original software package and the software package to be adapted) for the service running on the original distribution A (i.e., the original distribution of the software package). These packages are categorized and uploaded to the build environment corresponding to the target distribution B (i.e., the target build environment), such as a specific version of Linux. RPMrebuild and the RPMbuild tool package are then installed in this build environment.

[0140] Furthermore, the specific process of preparing the software package in step S301 is as follows: download the binary RPM package required for the business to run in the architecture where the original distribution version A is located, use the Linux command RPM-qp and append the --qf"%{SourceRPM}" parameter to obtain the source RPM package names of multiple RPM software packages that need to be adapted; then classify the software packages from the same source package and upload them to the Linux machine of the target distribution version B that has been installed in the corresponding architecture. When the yum source is connected, use the yum command to download the tool software packages RPMrebuild and RPMbuild to the target system.

[0141] Step S302: extract the sub-package specs, use RPMrebuild to extract the corresponding specs for each binary RPM package, and integrate these specs after modification.

[0142] Furthermore, the specific method for preparing and correcting the sub-package spec in step S302 is to use the RPMrebuild command with the edit-spec and package parameters, extracting the spec file for each sub-package and generating it in the .tmp directory under the current home directory. At this point, the spec is only used for each sub-package. If this spec is used directly, the source package information of the built software package will be the package itself, so it is necessary to correct the sub-package spec information and merge the specs.

[0143] Step S303: Modify the sub-package spec file, and modify the contents of the fields in the %package, %description, %files, %pre, and %post stages in each sub-package spec file according to the specific package information.

[0144] Further, the specific modification method of spec in step S303 is: for each sub-package spec outside the main package, first obtain the value of Name (i.e. the basic name) through grep and awk, such as bin_nameA. Then delete the line starting with Name by using sed, find the line starting with "BuildArch" and insert a new line before it %package -n bin_nameA, replace the line starting with "%description" with %description -n bin_nameA, replace the line starting with "%files" with %files -n bin_nameA, and append -n bin_nameA after the lines starting with %pre, %post, %trigger, and %verifyscript.

[0145] These parameters are added according to the packaging mechanism of spec and RPM package, and the package name of each stage needs to be specified, so that each RPM can contain its own correct content when rebuilding; at the same time, in order to prevent the binary, shared library, etc. in part of the compilation environment from being packaged as a dependency in the RPM package header due to different compilation environments, AutoReq: no needs to be added after the line starting with "%package". This step corresponds to the related content such as "updating the package name of each stage in the software package description file corresponding to the target sub-package to the target sub-package description file according to the stage to which the package name belongs, to obtain an intermediate description file; adding a first instruction for disabling automatic generation of runtime dependencies in the intermediate description file to avoid automatically generated incorrect runtime dependencies due to different software package build environments, to obtain a sub-software package description file".

[0146] The content of steps S304-S306 corresponds to the RPM package assembly and packaging part, i.e. the packaging stage, as shown in the accompanying drawings. Figure 5 The specific principle is as follows:

[0147] Step S304, generate the overall packaging spec, identify the main package spec and combine all sub-package specs into one spec file, such as C.spec.

[0148] Furthermore, the method for generating the overall package spec in step S304 is as follows: determine the main package spec through the field content of SourceRPM obtained in step S301 (i.e., the source code package name information), and then merge the contents of all sub-package specs in step S303 into the main package according to each stage, that is, the contents of each stage such as %package, %files, %description%, %pre, and %post are all merged into C.spec (i.e., the target software package description file).

[0149] Step S305: Create a temporary BUILDROOT directory D, and use the rpm2cpio command to decompress the contents of each binary package to the directory D (ie, a temporary directory).

[0150] Furthermore, the specific method of unpacking in step S305 is: enter the temporarily created BUILDROOT directory D, use RPM2cpio sub-package name for each sub-package one by one, and pass it to the cpio-idvm command through the pipe symbol to obtain the decompressed files of each sub-package, which usually have directories such as . / etc. / usr.

[0151] Step S306: Based on C.spec and the unpacked contents in directory D, use the RPMbuild command to rebuild the RPM package of the target release.

[0152] Furthermore, the software package rebuilding step in step S306 includes: using the RPMbuild command to define the buildroot directory macro, specifying all the prepared main package and sub-package files, and specifying the directory of C.spec, and packaging all the files according to the packaging order in C.spec and the pre-prepared rules.

[0153] In some embodiments, an example based on the above method is provided. In this example, a group of large-scale business RPM software packages p1, p2, and p3 are targeted, and it is assumed that the target machine is a Red Hat-like system. Specifically, the following steps are included:

[0154] Step 1: First, download all the required binary RPM packages p1, p2, and p3 from the source distribution A. Then, use the Linux command RPM -qp --qf "%{SourceRPM}" for each package to obtain the corresponding source RPM package name. Then, upload these source RPM packages to a Linux machine with the corresponding architecture of the target distribution B. On the target system, install the RPMrebuild and RPMbuild tools using the yum install command from the yum repository.

[0155] Step 2: Enter the directory where the RPM package in step 1 is located, and use RPMrebuild--e --package for the packages p1, p2, and p3 respectively.<package_name> A temporary spec file is generated in the middle of the build process. This file is directly generated in a directory similar to BuildRoot: / root / .tmp / RPMrebuild.700578 / work / root. The specific file directory will be prompted at the top of the terminal. Each sub-package's spec is only packaged from the sub-package itself, so it is necessary to archive the reverse spec file of each package to facilitate subsequent sub-package merging and modification operations.

[0156] Step 3: For the specs of p1, p2, and p3, each spec only builds its own package, and the resulting source package information is incorrect. However, specs provide renaming capabilities at each stage, allowing related software packages to be processed separately and unified in a single spec file. For example, based on the queried source package name, the corresponding names of the main package, subpackages, and source package can be unified.

[0157] First, use cat combined with the pipe symbol on p1.spec (similar operations for p2.spec and p3.spec) and use grep'Name:' and awk'{print $NF}' to get the real software name such as bin_nameA.

[0158] Then, you need to delete the line starting with Name and replace it with %package -n bin_nameA before the "BuildArch" line. This step is the key to sub-packaging the spec.

[0159] Next, you need to append -n bin_nameA to the lines beginning with "%description" and "%files" respectively, because these stages need to specify which package they belong to; otherwise, all the content will be incorrectly attributed to the main package. Similarly, use -n bin_nameA to separate each script stage (%pre, %post, %trigger, and %verifyscript).

[0160] Finally, considering that the RPM package mechanism will automatically scan the build environment information such as so files by default and add them to the runtime dependencies of the software package, you also need to add the AutoReq: no content after the "%package" line.

[0161] Step 4: In this step, the spec of the main package and the sub-package need to be distinguished first. Assuming that the main package is p2 in step 3 by the RPM-qp --qf "%{SourceRPM}" command in step 1, then p1.spec needs to be assembled based on p2.spec, and p3.spec is a C.spec. The contents of each stage, such as %package, %files, %description%, %pre, %post, etc. in p1.spec and p2.spec need to be merged. Then the final content of C.spec will have %package -n bin_nameA, %package -n bin_nameB, %files -n bin_nameA, %files -n bin_nameB stages and contents.

[0162] Step 5: After the packaging file C.spec is prepared, the specific files that need to be packaged, i.e. all the contents in the software package, need to be prepared. First, create a temporary BUILDROOT directory D, then use RPM2cpio package name to convert the software packages p1, p2, pc respectively, and then pass them to the pipe symbol using cpio -idvm to decompress the contents of these software packages to directory D. Usually, directories such as. / etc,. / usr and files under the directories will be generated in directory D.

[0163] Step 6: After the packaging script spec and the packaged content are prepared in directory D, the software package needs to be packaged using the RPMbuild command. Usually, the default directory used by RPMbuild is SPECS, SOURCES, BUILDROOT directory under the home directory / RPMbuild. This method is usually used in the case of existing src.rpm, using RPM -ivh, corresponding to the src.rpm package, the contents in src.rpm will be decompressed to the corresponding directory under the home directory / RPMbuild.

[0164] For this application, the RPMbuild command needs to be used to define the buildroot directory macro, specify all the prepared main package and sub-package files, and specify the directory of C.spec. According to the packaging order in C.spec, all files are installed according to the specified preparation rules to complete the packaging.

[0165] Currently, in the software package adaptation practice of RPM software package, the commonly used method is to obtain the open source source code RPM package of the component, and then solve the adaptation problem in the construction process by constructing the source code package, and finally generate a runnable binary RPM package. This method is relatively direct and effective when dealing with small or medium-sized components. However, when facing the adaptation of large upper-layer business components (it is more difficult to obtain src.rpm), the disadvantages of this method are particularly prominent. The above method provided by the application provides a more convenient and accurate reconstruction method for RPM software package adaptation workers in the distribution when it is difficult to obtain the source code RPM, quickly adapts some large business components, greatly shortens the adaptation time, and speeds up the business deployment. At the same time, the reconstruction process is optimized, and the business adaptation ability of the distribution is improved. Therefore, the above method has the following advantages: 1. Improve the adaptation efficiency and accuracy: by directly extracting and optimizing the spec file from the existing binary RPM package, the method of the application avoids the complex process of compiling the source code from scratch, greatly shortens the adaptation time. At the same time, this method reduces the errors that may occur in the manual compilation process, improves the accuracy of the adaptation process. Since it is directly based on the existing binary package, the compatibility and functionality of the final generated software package with the original component can be ensured. 2. Reduce the dependence on source code package: in many cases, the source code of a specific version of a component may no longer be open source or difficult to obtain. The method of the application allows users to adapt the software package without source code, as long as they have the binary package. This is particularly useful for large components that are difficult to obtain SRPM software packages, thereby widening the adaptation possibilities and enabling more software packages to be adapted and used.

[0166] It should be understood that, although each step in the flowchart involved in each embodiment as described above is shown in sequence according to the direction of the arrow, these steps are not necessarily executed in sequence according to the direction of the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in the flowchart involved in each embodiment as described above can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these steps or stages is not necessarily sequential, but can be alternately or alternately executed with at least part of other steps or steps or stages in other steps.

[0167] Based on the same inventive concept, embodiments of the present application also provide a software package construction device for implementing the software package construction method described above. The solution provided by this device is similar to the solution described in the method described above. Therefore, the specific limitations of one or more software package construction device embodiments provided below can be found in the limitations of the software package construction method described above and will not be further elaborated here.

[0168] In an exemplary embodiment, Figure 6 As shown, a software package construction device 600 is provided, including:

[0169] The acquisition module 601 is used to obtain the original released version of the original software package that is executable after compilation; the original software package includes sub-packages and software package description files corresponding to the sub-packages;

[0170] The modification module 602 is configured to determine the main package of the original software package from the sub-packages, and to use the sub-packages other than the main package as target sub-packages relative to the main package; modify the software package description file corresponding to the target sub-package to obtain a sub-software package description file; and merge the sub-software package description file into the software package description file corresponding to the main package in the original software package to obtain a target software package description file.

[0171] The construction module 603 is used to construct a temporary directory according to the sub-package, and obtain a target software package corresponding to the target release version of the target construction environment and executable after compilation based on the target software package description file, the temporary directory and the target construction environment.

[0172] In one embodiment, the correction module 602 is further configured to correct the software package description file corresponding to the target sub-package to obtain the sub-software package description file, including: obtaining a base name corresponding to the target sub-package; determining, based on the packaging mechanism and base name corresponding to the original software package, the package names of each stage in the software package description file corresponding to the target sub-package; and updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package to obtain the sub-software package description file.

[0173] In one embodiment, the correction module 602 is further configured to update the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package, respectively, to obtain the sub-software package description file, including: updating the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package according to the stages to which the package names correspond, to obtain the intermediate description file; and adding a first instruction for disabling automatic generation of runtime dependencies into the intermediate description file to avoid automatically generating erroneous runtime dependencies due to different software package build environments, to obtain the sub-software package description file.

[0174] In one of the embodiments, the correction module 602 is further configured to determine the main package of the original software package from the sub-packages, including: obtaining source code package name information corresponding to the original software package; and determining the main package of the original software package from the sub-packages according to the source code package name information.

[0175] In one of the embodiments, the construction module 603 is further configured to construct a temporary directory according to the sub-packages, including: constructing an initial directory; converting the sub-packages into archive files, and decompressing the archive files into the initial directory to obtain the temporary directory.

[0176] In one of the embodiments, the construction module 603 is configured to obtain the target software package belonging to the post-compilation executable target software package corresponding to the target distribution of the target construction environment based on the target software package description file, the temporary directory and the target construction environment, including: determining the target construction environment, and determining the packaging sequence in the target software package description file; and packaging the sub-packages in the temporary directory based on the packaging sequence to obtain the target software package belonging to the post-compilation executable target software package corresponding to the target distribution of the target construction environment.

[0177] Each of the modules in the above software package construction apparatus can be realized by software, hardware and combinations thereof in whole or in part. Each of the modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to be called and executed by the processor to perform the operations corresponding to each of the modules.

[0178] In an exemplary embodiment, a computer device is provided, which can be a server or a terminal, and an internal structure diagram thereof can be as shown in Figure 7 The computer device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database of the computer device is configured to store data required for executing the software package construction method, such as original software packages, target software packages, etc. The input / output interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device is configured to communicate with external terminals through network connection. The computer program is executed by the processor to implement a software package construction method.

[0179] Those skilled in the art can understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0180] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0181] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0182] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0183] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0184] The technical features of the above embodiments can be combined in any manner. To make the description concise, all possible combinations of the technical features in the above embodiments are not described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the present application.

[0185] The above-described embodiments are merely illustrative of several embodiments of the present application, which are described in more detail and in a specific manner, but should not be construed as limiting the scope of the patent of the present application. It should be noted that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A method for constructing a software package, characterized in that: The method comprises: Obtaining an original software package of an original release version under a Linux system that is executable after compilation; the original software package includes subpackages and software package description files corresponding to the subpackages; Obtaining source package name information corresponding to the original software package, determining a main package of the original software package from each of the sub-packages based on the source package name information, and using the remaining sub-packages in the sub-packages except the main package as target sub-packages relative to the main package; Get the base name corresponding to the target subpackage; Determining, based on the packaging mechanism corresponding to the original software package and the base name, the package names of each stage in the software package description file corresponding to the target sub-package; Update the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package according to the stages to which the package names correspond, to obtain an intermediate description file; Adding a first instruction for disabling automatic generation of runtime dependencies in the intermediate description file to avoid automatically generating incorrect runtime dependencies due to different software package build environments, thereby obtaining a sub-software package description file; Merging the sub-software package description file into the software package description file corresponding to the main package in the original software package to obtain a target software package description file; A temporary directory is constructed according to the sub-package, and based on the target software package description file, the temporary directory, and the target build environment under the Linux system, a target software package corresponding to the target release version of the target build environment under the Linux system is obtained, which is executable after compilation; the target software package and the original software package are binary RPM packages, and the target software package and the original software package are software packages of different versions.

2. The method according to claim 1, characterized in that The step of merging the sub-software package description file into the software package description file corresponding to the main package in the original software package to obtain a target software package description file includes: Based on the order of each stage in the software package description file, the sub-software package description file is merged into the software package description file corresponding to the main package in the original software package to obtain a target software package description file.

3. The method according to any one of claims 1 to 2, characterized in that The step of constructing a temporary directory according to the sub-package includes: Build the initial directory; The sub-package is converted into an archive file, and the archive file is decompressed into the initial directory to obtain a temporary directory.

4. The method according to any one of claims 1 to 2, characterized in that The step of obtaining a target software package that is executable after compilation and corresponds to a target release version of the target construction environment based on the target software package description file, the temporary directory, and the target construction environment includes: Determine the target build environment and determine the packaging order in the target software package description file; The sub-packages in the temporary directory are packaged based on the packaging order to obtain a target software package that is executable after compilation and corresponds to a target release version of the target construction environment.

5. A software package construction device, characterized in that: The device comprises: An acquisition module is used to obtain an original software package of the original release version under the Linux system that is executable after compilation; the original software package includes sub-packages and software package description files corresponding to the sub-packages; a correction module, configured to obtain source package name information corresponding to the original software package, determine the main package of the original software package from each of the sub-packages based on the source package name information, and use the remaining sub-packages in the sub-package except the main package as target sub-packages relative to the main package; obtain a base name corresponding to the target sub-package; determine the package names of each stage in the software package description file corresponding to the target sub-package based on the packaging mechanism corresponding to the original software package and the base name; update the package names of each stage in the software package description file corresponding to the target sub-package into the software package description file corresponding to the target sub-package according to the stage to which the package names correspond, to obtain an intermediate description file; add a first instruction for disabling automatic generation of runtime dependencies in the intermediate description file to avoid automatically generating erroneous runtime dependencies due to different software package build environments, to obtain a sub-software package description file; merge the sub-software package description file into the software package description file corresponding to the main package in the original software package, to obtain a target software package description file; The construction module is configured to construct a temporary directory according to the sub-package and obtain, based on the target software package description file, the temporary directory, and the target construction environment under the Linux system, a target software package corresponding to the target release version of the target construction environment under the Linux system, which is executable after compilation; the target software package and the original software package are binary RPM packages, and the target software package and the original software package are software packages of different versions.

6. The device according to claim 5, characterized in that The building block is further used to: Build the initial directory; The sub-package is converted into an archive file, and the archive file is decompressed into the initial directory to obtain a temporary directory.

7. The device according to claim 5, characterized in that The building block 603 is further configured to: Determine the target build environment and the packaging order in the target software package description file; The sub-packages in the temporary directory are packaged based on the packaging order to obtain the target software package that is executable after compilation and corresponds to the target release version of the target build environment.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 4 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images