Packaging method of application program, storage medium, electronic device, and program product

Abstract

Embodiments of the present application provide a packaging method of an application program, a storage medium, an electronic device and a program product. The method comprises: installing, in a packaging system, a source system comprising an original basic running and an original development environment of a packaged application program by a package management tool, wherein the package management tool of the packaging system is the same as that of the source system, and the source system is a system in which the application program is originally expected to run before being packaged; compiling a control program in the source system, setting a dynamic link loader path of the control program as a placement path of an internal loader after package installation, and storing the control program under a packaging directory; and generating an application program installation package according to files under the packaging directory. Through the embodiments of the present application, the problem that a cross-system application program packaged and generated in the related art has incompatibility and large overhead when running is solved.

Description

Technical Field

[0001] This application relates to the field of software packaging, and more specifically, to a method for packaging applications, a storage medium, an electronic device, and a program product. Background Technology

[0002] In the field of software packaging, application packaging is a crucial step to ensure that applications and their dependent components can run stably in different system environments. Traditional application packaging methods, such as deb and rpm, while providing convenience for software installation and management, are limited by specific system distribution versions. This means that applications need to be recompiled and repackaged to run on different systems, increasing the complexity and cost of application distribution.

[0003] To address software compatibility issues across different system distributions, several cross-system packaging technologies have been developed, such as AppImage, Flatpak, and Snap. While these technologies achieve cross-system operation to some extent, they also have limitations and problems. When packaging applications using these technologies, sandboxing is created, consuming additional system resources. This is especially problematic in multi-command application scenarios, where frequent sandbox startup and resource allocation lead to significant performance degradation. Furthermore, because the application runs within a sandbox environment during packaging, its interaction with other parts of the system is restricted, reducing application flexibility, particularly in scenarios requiring the invocation of native system commands or access to specific system resources. Summary of the Invention

[0004] This application provides a method for packaging an application, a storage medium, an electronic device, and an application product, to at least solve the problems of incompatibility and high overhead that occur when cross-system applications are packaged and run in the related art.

[0005] According to one embodiment of this application, a method for packaging an application is provided, comprising: installing a source system, including the original basic runtime and original development environment of the application to be packaged, in a packaging system using a package management tool, wherein the package management tool of the packaging system is the same as that of the source system, and the source system is the system originally intended to run the application before it is packaged; compiling a control program in the source system, setting the dynamic link loader path of the control program to the placement path of the loader inside the package after installation, and storing the control program in a packaging directory; and generating an application installation package based on the files in the packaging directory.

[0006] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the steps in the above method embodiments when it is run.

[0007] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in the above method embodiments.

[0008] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0009] Through the embodiments described above, the environment of the source system is copied and installed in the packaging system, ensuring that the system environment during the packaging process is consistent with the environment in which the application was originally intended to run. This avoids problems such as application packaging failure or abnormal operation due to environmental differences, and enhances the stability of the application on different systems. Compiling the control program in the source system ensures that the control program is compatible with the dynamic link loader of the source system. Pointing the dynamic link loader path of the control program to the loader inside the package means that the application will use the dynamic link loader built into the package at runtime, instead of the system default loader. This not only avoids the problem of inconsistent dynamic link loader versions between different systems, but also allows the control program to dynamically correct environment variables at runtime, ensuring that the library files required for the correct operation of the application can be found. Therefore, the problems of incompatibility and high overhead that occur when cross-system applications are packaged in related technologies can be solved. Attached Figure Description

[0010] Figure 1 This is a hardware structure block diagram of a computer terminal for an application packaging method according to an embodiment of this application;

[0011] Figure 2 This is a flowchart of an application packaging method according to an embodiment of this application;

[0012] Figure 3 This is a structural block diagram of an application packaging device according to an embodiment of this application;

[0013] Figure 4 This is a flowchart of an application packaging method according to another embodiment of the present application;

[0014] Figure 5 This is a deployment structure diagram of the application installation package according to an embodiment of this application;

[0015] Figure 6 This is a flowchart of the control procedure processing according to an embodiment of this application;

[0016] Figure 7 This is a flowchart of the control procedure processing according to another embodiment of the present application. Detailed Implementation

[0017] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of the computer terminal used in the embodiments of the method of this application. For example... Figure 1 As shown, a computer terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0020] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the application packaging method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0021] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0022] Figure 2 This is a flowchart of an application packaging method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0023] Step S202: Install the source system, which includes the original basic running environment and original development environment of the packaged application, in the packaging system using the package management tool. The packaging system uses the same package management tool as the source system, and the source system is the system that the application was originally intended to run before being packaged.

[0024] In one embodiment, the application packaging method of this application is applied to a Linux system, where the packaging system and the source system are the same Linux system, or different versions of Linux systems with the same architecture.

[0025] In an exemplary embodiment of this application, installing the source system, which includes the original runtime and development environment of the packaged application, in the packaging system using a package management tool includes: installing the source system, which includes the original runtime and development environment of the application, in a temporary directory using the same package management tool and packaging configuration file as the source system; wherein, the packaging configuration file includes symbolic link information and a package repository address, the symbolic link information is used to indicate the list of files for which symbolic links need to be created, and the package repository address is used to provide the packages included in the application and the original runtime environment.

[0026] It's important to note that the selection and use of package management tools are crucial to the packaging process. Ensuring the packaging system's environment is consistent with the source system, accurately collecting all dependencies, and through standardized processing by the tools, guarantees that the final application installer can run on different system distributions without requiring additional environment configuration or dependency installation. This significantly simplifies the deployment and operation of cross-system applications, improving software portability and user experience.

[0027] In one embodiment, symbolic link information is used during the package installation and enabling phase to provide file information that interacts with the system, including scripts, configuration files, log files, data storage files, service configuration files, etc., which will be used during application runtime. Files that will be accessed at specified paths during application runtime need to be specified.

[0028] In an exemplary embodiment of this application, the packaging configuration file further includes at least one of the following: an application name, used to indicate the name of the packaged application; an application version number, used to indicate the version number of the packaged application; an application description; a list of package names, used to indicate information about the packaged object; and pre- and post-installation / uninstallation scripts, used to customize the actions during application installation and uninstallation.

[0029] In an exemplary embodiment of this application, before compiling the control program line in the source system, the method further includes: extracting files from the software package from the source system; collecting the dependent libraries and base libraries required for the software package to run based on the files, wherein the base libraries include library files related to the dynamic link loader's operation; resetting the paths of the dynamic link loader in the executable and linkable format (ELF) files in the files, base libraries, and dependent libraries to an absolute path, the absolute path pointing to the placement path of the loader inside the package after package installation; removing the runtime library paths of all ELF files; and storing all processed files in the packaging directory according to the original directory structure.

[0030] It should be noted that the paths of the dynamic linkers in the executable and linkable ELF files in the files, base libraries, and dependency libraries are reset to absolute paths. This is because the installation and deployment paths of the files within the application package are fixed during packaging, and after the application package is installed, the application files in the package will be deployed to the expected specified locations.

[0031] In this embodiment, the runtime library paths (rpath) of all ELF files are removed. This is done to prevent the runtime library paths from interfering with the search for dynamic libraries. Then, all the extracted files are stored in a newly created packaging directory, maintaining the original directory structure.

[0032] In an exemplary embodiment of this application, collecting the dependent libraries required for the operation of the software package based on files includes: collecting dependent libraries by using the List Dynamic Dependencies (ldd) command on all dynamically linked files in the software package, obtaining the shared libraries and paths that the dynamic links depend on, and using the ldd command on the shared libraries until all dependent libraries are found.

[0033] The collection of complete dependency libraries ensures that all dynamic library dependencies required for the application to run are collected when packaging the application, including both direct and indirect dependencies. The ldd command is used to list the dynamic linking dependencies of executable files or shared libraries. By using ldd recursively, all shared libraries directly or indirectly called by the application can be found layer by layer, thus avoiding errors caused by missing dependency libraries when running on the source system.

[0034] In an exemplary embodiment of this application, creating an application installation package based on files in the packaging directory includes: creating an application installation package from the management program, metadata, and files in the packaging directory.

[0035] In an exemplary embodiment of this application, the metadata includes at least one of the following: symbolic link information, length and starting address of each region, application information, dependency information, provided functional information, scripts to be executed before and after installation and uninstallation, and signature information.

[0036] In one embodiment, the management program is an executable program that is responsible for package installation, uninstallation, information viewing, signature verification, and so on. When a package is executed as a program, the management program is essentially manipulating metadata and application data.

[0037] In an exemplary embodiment of this application, the regions include: a management region, a metadata region, and an application data region.

[0038] Step S204: Compile the control program in the source system, set the dynamic link loader path of the control program to the placement path of the internal loader of the package after package installation, and store the control program in the package directory.

[0039] In one embodiment, the control program is written in C. It is compiled on the source system because it requires the source system's dynamic link loader. This prevents the control program from failing to start due to incompatibility with the dynamic link loader. After compilation, the path to the dynamic link loader in the control program is set to the path where the loader is placed after package installation.

[0040] Step S206: Generate the application installation package based on the files in the packaging directory.

[0041] In an exemplary embodiment of this application, when installing an application installation package, the application installation package manager deploys the files in the application installation package to a newly specified directory and creates symbolic links to the root directory based on the symbolic link information in the application installation package.

[0042] Deploying the application and all its dependencies centrally in a newly created directory, rather than scattering them across the system's default directories, provides the application with an isolated and controlled runtime environment. Even if the application contains many different command entry points, they can be organized and managed within an independent directory structure, preventing conflicts with other applications or library files on the system.

[0043] Creating symbolic links in the root directory allows users or the system to invoke multi-entry commands of the application as if they were commands natively installed in the system, thus achieving the technical effect of installing applications with multi-entry commands.

[0044] In an exemplary embodiment of this application, creating symbolic links in the root directory based on symbolic link information in the application installation package includes at least one of the following: uniformly pointing the symbolic links of executable files to the control program of this application; pointing the symbolic link files to the original target; pointing other files to the corresponding entity files in the installation directory.

[0045] Pointing all symbolic links of executable files to the application's control program enhances the application's controllability and security. Pointing symbolic links to their original targets maintains the original file linking relationships. Pointing other files to their corresponding entity files in the installation directory optimizes file access efficiency and reduces resource consumption.

[0046] In an exemplary embodiment of this application, upon receiving an instruction to run an application, the control program sets the preloaded dynamic library environment variable to the path of a special dynamic library file; it starts a child process to preferentially load the special dynamic library so that the execution function in the special dynamic library will be called before the function with the same name in the system default library; and it starts the actual program to be executed in the child process by calling the rewritten execution function.

[0047] In an exemplary embodiment of this application, the execution function includes at least one of the following: an execution file path search function, a dynamic path modification function, a dynamic library search path function, a function to preload dynamic library environment variables, and a function with the same name in the system default library.

[0048] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0049] This embodiment also provides an application packaging device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0050] Figure 3 This is a structural block diagram of an application packaging device according to an embodiment of this application, such as... Figure 3 As shown, the device includes an installation module 10, a storage module 20, and a manufacturing module 30.

[0051] Install module 10 is used to install the source system, including the original base running and original development environment of the packaged application, in the packaging system through the package management tool. The packaging system and the source system have the same package management tool, and the source system is the system that the application was originally expected to run before being packaged.

[0052] The storage module 20 is used to compile the control program in the source system, set the dynamic link loader path of the control program to the placement path of the internal loader of the package after package installation, and store the control program in the packaging directory.

[0053] The storage module 20 is also used to put all files in the packaged software package, all collected dependency libraries and base libraries into the packaging directory.

[0054] Module 30 is used to create an application installation package based on the files in the packaging directory.

[0055] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0056] To facilitate understanding of the technical solutions provided in the application embodiments, the following description is based on specific scenario embodiments.

[0057] Scenario Example 1

[0058] Figure 4 This is a flowchart of an application packaging method according to another embodiment of the present application, such as... Figure 4 As shown, the process includes the following steps:

[0059] Step S401: Enter the packaging configuration file.

[0060] Specifically, the packaging configuration file includes at least one of the following: symbolic link information, package repository address, application name, application version number, application description, list of package names, and pre- and post-installation / uninstallation scripts.

[0061] Step S402: Parse the packaging configuration file.

[0062] Specifically, the symbolic link information indicates the list of files for which symbolic links need to be created. During the package installation and enabling phase, it provides information on files that interact with the system, including scripts, configuration files, log files, data storage files, service configuration files, etc., used during application runtime. Theoretically, only files that will be accessed at the specified path during application runtime need to be filled in. The package repository address provides the packages included in the application and their original runtime environment. The application name indicates the name of the packaged application. The application version number indicates the version number of the packaged application. The package name list indicates information about the packaged objects. The pre- and post-installation / uninstallation scripts are used to customize the actions during application installation and uninstallation.

[0063] Step S403: Install and deploy the source system.

[0064] Specifically, a source system is installed and deployed using the repository specified in the configuration file. This step requires that the packaging system and the source system use the same package management tool, allowing the package management tool to install and deploy the source system in a temporary directory. The source system needs to have the packaged software package and all its dependencies installed, as well as the gcc and glibc packages and all their dependencies. Here, gcc is used to compile control programs, and glibc provides the dynamic linker, ensuring that each packaged application uses the original system's dynamic linker.

[0065] Step S404, extraction processing.

[0066] The process involves extracting all files from the source system, collecting all its dependent libraries and base libraries, and gathering package component information, dependency information, and installation / uninstallation status. Dependency libraries are collected by using the `ldd` command on all dynamic linker files of the target RPM. The `ldd` command lists the shared libraries it depends on and their paths. This process is repeated for newly found shared libraries until all dependencies are found. Base libraries primarily consist of libraries related to the dynamic linker loader's execution. After file collection, the paths of the dynamic linker loader's interpreter for ELF files are reset. These paths are set to absolute paths because the installation and deployment paths of files within the application package are fixed during packaging, and the application files are deployed to the expected locations after installation. Then, the rpaths of all ELF files are removed to prevent them from interfering with the search for dynamic libraries. Finally, all extracted files are stored in a newly created packaging directory, maintaining the original directory structure.

[0067] Step S405: Compile the control program.

[0068] The control program's source code is compiled into the source system. This control program is written in C. Compiling it within the source system is necessary to use the source system's dynamic link loader, preventing incompatibility issues that could prevent the control program from starting. After compilation, the path to the dynamic link loader (Interpreter) in the control program is set to the path where the loader will be placed after package installation. Then, the control program is also placed in the package directory.

[0069] Step S406: Packaging.

[0070] Specifically, the management program, the various information collected, and the files in the package directory are compiled into a single package.

[0071] Scenario Example 2

[0072] In an exemplary embodiment of this application, when installing an application installation package, the management program in the package header will install and deploy the files in the package to a newly created directory, and then create a symbolic link to the root directory based on the symbolic link information in the metadata of the package.

[0073] The symbolic link information to be created comes from the packaging configuration file and is divided into three categories: executable files, symbolic link files, and other files. The symbolic links to be created in these three categories are all located in the original package installation location, but they point to different targets:

[0074] If it is an executable file, symbolic links should all point to the control program of this application;

[0075] If it is a symbolic link file, then keep the original target that the symbolic link points to;

[0076] If it is another file, it will point to the corresponding physical file in the installation directory.

[0077] After the symbolic links are established, the deployment structure of the application installation package is as follows: Figure 5 As shown, Figure 5 The root directory ( / ) is the system's basic directory. It includes the bin / directory, the etc / directory, and the installation directory. The bin / directory contains executable files for applications and symbolic links to these programs, which point to the application's control program. The etc / directory contains symbolic links; for configuration files, these links directly point to the corresponding configuration files within the installation directory. The installation directory includes the control program, the bin / subdirectory, and the etc / subdirectory. The bin / subdirectory contains the programs, and the etc / subdirectory contains the configuration files.

[0078] Scenario Example 3

[0079] In an exemplary embodiment of this application, the cross-system operation of the application is achieved through a control program. The control program contains a special dynamic library file, in which functions such as execvp, execve, execv, execl, execlp, and dlopen are written. These functions have functions with the same names in the system's default library. The purpose of rewriting these functions here is to ensure that the behavior of the functions is controlled as expected when the application calls these functions.

[0080] For the `exec` family of functions, these functions are all used to start child processes to execute new programs, and the processing of these functions is similar. During application runtime, if a command from within a package is called, the overridden function will automatically add the corresponding path under the application's installation path to the beginning of the `PATH` (path) and `LD_LIBRARY_PATH` (dynamic library search path) environment variables, ensuring that the dependencies of commands called from within the package come from within the package. If a command not from within a package is called, the overridden function will automatically remove the entries containing the application's installation path from the `PATH`, `LD_LIBRARY_PATH`, and `LD_PRELOAD` (preload dynamic libraries) environment variables, ensuring that the execution of commands not from within the package is not affected by files within the package. The structure of the overridden function is shown below:

[0081] functionName(parameters){;

[0082] Use the dlsym function to get the address of a function with the same name in the system's default library;

[0083] If the program to be executed is located in the application installation directory;

[0084] Then add the paths to the bin, lib, and other directories under the application installation path to the beginning of the environment variables PATH and LD_LIBRARY_PATH;

[0085] };

[0086] otherwise{;

[0087] Remove entries in the environment variables PATH, LD_LIBRARY_PATH, and LD_PRELOAD that contain the application installation path;

[0088] };

[0089] Execute the function with the same name in the system's default library;

[0090] }

[0091] The `dlopen` function is used to load dynamic libraries. During application runtime, if a dynamic library from the application package needs to be loaded, the corresponding path under the application's installation path is added to the beginning of `LD_LIBRARY_PATH`; if a dynamic library not from the package needs to be loaded, all entries containing the installation path in `LD_LIBRARY_PATH` are removed. This ensures that the dynamic library and its dependencies can be correctly found when loading. The rewritten structure of the `dlopen` function is as follows:

[0092] dlopen(parameters){;

[0093] Use the dlsym function to get the address of the dlopen function in the system's default library;

[0094] If the dynamic library to be loaded is found in the installation directory;

[0095] Then add the path to directories such as lib under the application installation path to the beginning of the environment variable LD_LIBRARY_PATH;

[0096] };

[0097] otherwise{;

[0098] Remove the entry in the environment variable LD_LIBRARY_PATH that contains the application installation path;

[0099] };

[0100] Execute the dlopen function in the system's default library;

[0101] Restore the modified LD_LIBRARY_PATH environment variable;

[0102] }

[0103] The application links to the control program via symbolic links. When a user runs the application, the control program runs first. The control program sets the LD_PRELOAD environment variable to the path of a specific dynamic library file and then starts a child process to load the specific dynamic library first. Functions within this dynamic library are used before their counterparts in the system's default library, effectively hijacking calls to these system functions. The child process then calls the overridden execvp function to start the actual program. Later, if the application calls execvp, execve, or similar functions again, the overridden functions are executed, dynamically modifying the aforementioned settings. This mechanism ensures that multi-command entry points allow the application to run correctly when calling itself or native system commands.

[0104] In an exemplary embodiment of this application, for scenarios where no other commands are invoked during application operation, the control program's processing flow is as follows: Figure 6 As shown, the process includes the following steps:

[0105] Step S601: The user enters a command to run the application;

[0106] Step S602: The control program sets LD_PRELAOD (preload dynamic library);

[0107] Step S603: Start the subroutine to load the special dynamic library;

[0108] Step S604: Call the rewritten execvp function to execute the new program;

[0109] Step S605: The rewritten execvp adds the application installation directory to the environment variables PATH and LD_LIBRARY_PATH (dynamic library search path);

[0110] Step S606: Call the execvp function in the system default library to run the application.

[0111] In an exemplary embodiment of this application, for a multi-command entry application, in a scenario where a command entry calls other commands of the same application again during runtime, the control program's processing flow is as follows: Figure 7 As shown, this assumes that the application internally calls other commands through functions in the exec family of functions. The process includes the following steps:

[0112] Step S701: The user enters a command to run the application;

[0113] Step S702: The control program sets LD_PRELAOD;

[0114] Step S703: The startup subroutine loads the special dynamic library;

[0115] Step S704: Call the rewritten execvp function to execute the new program;

[0116] Step S705: The rewritten execvp adds the application installation directory to the environment variables PATH and LD_LIBRARY_PATH;

[0117] Step S706: Call the execvp function in the system default library to run the application;

[0118] In step S707, if the application uses the execvp function to call other commands within the application, the execvp function is hijacked and the rewritten execvp function is executed.

[0119] It should be noted that the environment variables PATH and LD_LIBRARY_PATH already contain the application installation path and do not need to be modified.

[0120] Step S708: Call the execvp function in the system default library to run the application.

[0121] In an exemplary embodiment of this application, if the application calls a system command during runtime, the overridden function will delete all entries containing the application installation path in PATH, LD_LIBRARY_PATH, and LD_PRELOAD, and then continue to execute the function with the same name in the system default library.

[0122] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0123] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0124] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0125] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0126] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0127] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0128] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for packaging an application, characterized in that, include: The packaging system uses a package management tool to install the original base operating and development environment of the packaged application. The packaging system is the same as the package management tool of the source system, and the source system is the system that the application was originally intended to run before being packaged. Extract files from the source system into the software package; collect the dependent libraries and base libraries required for the software package to run based on the files; the base libraries include library files related to the dynamic link loader's operation; reset the paths of the dynamic link loader in the executable and linkable ELF files in the files, base libraries, and dependent libraries to an absolute path, the absolute path pointing to the location of the loader inside the package after installation; remove the runtime library paths of all the ELF files; and store all processed files in the packaging directory according to the original directory structure. The control program is compiled in the source system, the dynamic link loader path of the control program is set to the placement path of the internal loader of the package after package installation, and the control program is stored in the package directory. The application installation package is generated based on the files in the package directory.

2. The method according to claim 1, characterized in that, The installation of the source system, including the original runtime and development environment of the packaged application, through the package management tool in the packaging system includes: In the packaging system, the original base runtime and original development environment of the application are installed in a temporary directory using the same package management tool and packaging configuration file as the source system. The packaging configuration file includes symbolic link information and a package repository address. The symbolic link information is used to indicate the list of files for which symbolic links need to be created, and the package repository address is used to provide the packages included in the application and the original runtime environment.

3. The method according to claim 1, characterized in that, The process of collecting the dependency libraries required for the software package to run based on the file includes: The dependency libraries are collected by using the `ldd` command to list dynamic library dependencies on all dynamic link files in the software package. The shared libraries and their paths that the dynamic links depend on are obtained, and the `ldd` command is used on the shared libraries until all dependency libraries are found.

4. The method according to claim 1, characterized in that, The step of creating an application installation package based on the files in the packaging directory includes: creating an application installation package from the management program, metadata, and the files in the packaging directory.

5. The method according to claim 4, characterized in that, in, The metadata includes at least one of the following: symbolic link information, length and starting address of each region, application information, dependency information, provided function information, scripts to be executed before and after installation and uninstallation, and signature information.

6. The method according to claim 5, characterized in that, in, The areas include: the management area, the metadata area, and the application data area.

7. The method according to claim 2, characterized in that, The package configuration file also includes at least one of the following: Application name, used to indicate the name of the packaged application; Application version number, used to indicate the version number of the packaged application; Application description; A list of package names that indicates information about the packaged objects; The pre- and post-installation scripts are used to customize the actions during the installation and uninstallation of the application.

8. The method according to claim 1, characterized in that, The method further includes: When the application installation package is installed, the application installation package management program will install and deploy the files in the application installation package to the specified newly created directory, and create symbolic links to the root directory according to the symbolic link information in the application installation package.

9. The method according to claim 8, characterized in that, Creating symbolic links in the root directory based on symbolic link information in the application installation package includes at least one of the following: Set all symbolic links of executable files to point to the control program of this application; Set the symbolic link file to point to the original target; Set other files to the corresponding entity files in the installation directory.

10. The method according to claim 1, characterized in that, The method further includes: Upon receiving an instruction to run the application, the control program sets the preloaded dynamic library environment variable to the path of a special dynamic library file; By starting a subprocess, the special dynamic library is loaded preferentially, so that the functions in the special dynamic library will be called before the functions with the same name in the system default library. The actual program to be executed is started in the child process by calling the rewritten execution function.

11. The method according to claim 10, characterized in that, The execution function includes at least one of the following: an execution file path search function, a dynamic path modification function, a dynamic library search path function, a function to preload dynamic library environment variables, and a function with the same name in the system default library.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 11.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 11.

Images