Method and system for querying rpm package version and path in yum source

Abstract

The application discloses a method and system for querying rpm package version and path in a yum source, relates to the field of operating systems in IT and software development, and comprises the following steps: determining the root directory of the Yum source, acquiring the same directory as the Yum source path in the local source, writing the query result into a file A, and cutting out the Yum source path and storing the same into a file B; acquiring the information of all package names based on the file A and storing the same into a file C as key information during the query; acquiring the complete version information of all packages based on the file A and storing the same into a file D, wherein the version information is composed of epoch and version-release; according to the stored information, splicing and formatting into a JSON file in the form of 'package name-version-path'; periodically detecting and updating the JSON file and synchronizing to the corresponding service directory. The package management system based on the Yum source has the characteristics of data accuracy, real-time updating and user friendliness, and can provide basic service capabilities for users to improve the Yum source and Linux distribution provider by using the own data and advantages.

Description

TECHNICAL FIELD

[0001] The application relates to the field of operating systems in IT and software development, and more particularly to a method and system for querying rpm package versions and paths in a yum source. BACKGROUND

[0002] A yum source is a source of an RPM software installation package in a Linux system, and usually, one type of Linux distribution corresponds to a yum source to continuously provide service capabilities of the Linux distribution. The yum source is provided to a user in a web form, and a provider of the yum source needs to create a local source on a local server and then synchronize local updates to the yum source, so that the yum source and the local source data are consistent. After a user configures a usable repo file under an / etc / yum.repos.d / directory of the Linux distribution, the system parses a repodata file in a specified yum source path (the file records paths, versions and dependencies of all RPM software packages under a directory of the repodata), and the user can use a yum command to perform online query, installation and uninstallation and other management on the RPM software package.

[0003] At present, in the official yum source corresponding to a mainstream Linux distribution, there are several to tens of software directories according to the categories of software packages, and different repodata are placed in different directories according to architectures. This configuration method is convenient for yum management to prevent confusion, but has a disadvantage that when it is necessary to query whether a Linux distribution being used supports a certain RPM software and the repodata path and version of the software, the yum source path of the software needs to be known first, and if the configured repo does not contain information of the software package, the package information cannot be obtained by direct query.

[0004] Therefore, how to conveniently and efficiently obtain the yum source path of the software is a technical problem to be solved at present. SUMMARY

[0005] The application provides a method and system for querying rpm package versions and paths in a yum source to solve the problem that it is difficult to conveniently and efficiently obtain the yum source path of the software.

[0006] In one aspect, the application provides a method for querying rpm package versions and paths in a yum source, comprising the following steps.

[0007] Step 1, determining a root directory of the yum source, and obtaining a directory in a local source which is the same as a yum source path, writing a query result into a file A, and cutting out the yum source path and storing it into a file B;

[0008] Step 2, based on file A to obtain all package name information, and stored in file C as the key information when querying;

[0009] Step 3, based on file A to obtain all package complete version information, and stored in file D, version information consists of epoch, version-release;

[0010] Step 4, according to the stored information, splicing and formatting into the "package name-version-path" form of JSON file;

[0011] Step 5, regularly detect and update JSON file, and synchronize to the corresponding service directory;

[0012] Step 6, provide a web interface for users to show, users only need to input package name and submit to obtain JSON file data.

[0013] Preferably, the query method and storage process in step 1 is:

[0014] The complete path of all rpm package files in the same directory in the local source is queried by the find command in linux and redirected to file A, and the corresponding path of the yum source is cut out by awk by comparing the actual root path of the yum source, and redirected to file B.

[0015] Preferably, the specific method for obtaining each package name information in step 2 is:

[0016] Use cat file A, then use pipe symbol " | " and use xargs to pass parameters to rpm–q command, and use queryformat parameter to query package name, get separate version number and architecture information, and redirect all the information queried to new storage file C.

[0017] Preferably, the method for obtaining complete version information of each package in step 3 is:

[0018] By cat file A, use pipe symbol and xargs command to pass information in file A to rpm query command and use queryformat parameter to print epoch:version-release format version information, and use sed command to intercept the version information for which the epoch itself is empty, finally redirect the version information to storage file D.

[0019] Preferably, the way of splicing and obtaining the final JSON file in step 4 is:

[0020] Use the paste command to combine files C, D, and B into file E by rows, and file E is the key-value correspondence relationship of RPM package name, package version information and Yum source path; and use the jq command to process each set of correspondence in file E into a json object and redirect it to json file F.

[0021] Preferably, the method for timing updating the json file in step 5 is:

[0022] Integrate the process tool for generating json file F into the crontab of the local source server, and before executing the process for generating json, judge whether all processes of steps 1-5 need to be performed by calculating the MD5 value of file A; if the MD5 value of the new file A is the same as the old MD5 value, it means that the Yum source data has not changed, and the json file does not need to be updated; after updating and generating a new json file, use the cp / scp command to update the json file to the same directory of the html file in step 2, so as to complete the updating of the json file and maintain the data timeliness of the query tool.

[0023] Preferably, the use mode shown to the user in step 6 is:

[0024] Generate a simple static search box containing a search input box and a clickable search button through html, and associate it with a custom function G in javascript through the onclick event to realize interaction, so that when the "search" button is clicked, the javascript passes the initial page number and the package name to the backend nodejs, the backend nodejs queries the json file through the package name and the current page number and returns only the current page content and the total count to function G, function G passes the json and the total count to function H, H displays the data of the current page according to the total count and the json to the front end, and judges whether the page number click event occurs, if it occurs, function G is called to query the data of the page.

[0025] On the other hand, the present application proposes a system for querying rpm package version and path in Yum source, comprising:

[0026] An information processing module is configured to determine a root directory of a Yum source, and obtain a directory in a local source that is the same as a Yum source path, write a query result into a file A, and cut out the Yum source path and store it into a file B; the information processing module is further configured to obtain information of all package names based on the file A, and store the information into a file C as key information during a query; the information processing module is further configured to obtain complete version information of all packages based on the file A, and store the version information into a file D, the version information being composed of epoch, version-release; according to the stored information, a JSON file in a form of "package name-version-path" is spliced and formatted;

[0027] An automatic detection module is configured to periodically detect and update the JSON file, and synchronize the JSON file to a corresponding service directory;

[0028] An interaction module is configured to provide a Web interface for a user to display, and the user can obtain JSON file data by only inputting a package name and submitting.

[0029] Preferably, a query method and a storage process of the information processing module are as follows:

[0030] A find command in Linux is used to query complete paths of all rpm package files in the same directory in the local source, and the complete paths are redirected and stored into a file A; an awk command is used to cut out paths that are the same as the Yum source, and the paths are redirected and stored into a file B;

[0031] A specific method of the information processing module to obtain information of each package name is as follows:

[0032] A cat file A is used, a pipe symbol " | " is used, and an xargs command is used to pass parameters to an rpm–q command in segments, and a queryformat parameter is used to query a package name, so that separate information without a version number and an architecture is obtained, and all the obtained information is redirected and stored into a new storage file C;

[0033] A method of the information processing module to obtain complete version information of each package is as follows:

[0034] A cat file A is used, a pipe symbol and an xargs command are used to pass information in the file A to an rpm query command, a queryformat parameter is used to print epoch:version-release format version information, a sed command is used to cut off version information in which the epoch itself is empty, and finally the version information is redirected and stored into a storage file D;

[0035] A method of the information processing module to splice and obtain a final JSON file is as follows:

[0036] The paste command is used to combine files C, D and B into file E by line, and file E is the key-value pair of RPM package name, package version information and Yum source path; the jq command is used to process each group of corresponding relations in file E into a json object and redirect it to json file F.

[0037] Preferably, the automatic detection module updates the json file in a timely manner by the following method:

[0038] The process tool for generating json file F is integrated into the local source server's crontab task, and before the process of generating json is executed, the MD5 value of file A is calculated to determine whether all processes in the information processing module need to be performed; if the MD5 value of the new file A is the same as the old MD5 value, it means that the Yum source data has not changed, and the json file does not need to be updated; after the new json file is generated, the cp / scp command is used to update the json file to the html file directory of the information processing module in a timely manner, so as to complete the update of the json file and maintain the data timeliness of the query tool;

[0039] The automatic detection module displays the following usage to the user:

[0040] A simple static search box containing a search input box and a clickable search button is generated through html, and the onclick event is associated with the custom function G in javascript to realize interaction, so that when the "search" button is clicked, the javascript passes the initial page number and the package name to the backend nodejs, the backend nodejs queries the json file through the package name and the current page number and returns only the current page content and the total count to function G, G passes the json and the total count to function H, H displays the data of the current page according to the total count and the json to the front end, and judges whether the page number click event occurs, if it occurs, function G is called to query the data of the page.

[0041] By applying the above technical solutions, the method and system for querying rpm package version and path in the Yum source have the following technical effects:

[0042] 1. Simplify the workflow of users and providers. Starting from the official Yum source, the key-value corresponding relationship is extracted by processing and sorting the information of all RPM packages in the local source, and the relationship information is stored as a json object. At the same time, the timeliness of the queried data is ensured by regular updating, and only one deployment is needed without manual maintenance. Through html+nodejs, the entrance of RPM package query is provided to Linux distribution users in the form of a web page. Users only need to open the query web page to input the RPM package name in the search box to query and obtain the result. Compared with manual configuration of repo file, this method is more convenient and ensures the accuracy of the result because the data comes from the official source, avoiding omission.

[0043] 2. Improve the basic service capability of Linux distribution. By further sorting and processing the local synchronization data of Yum source and providing it to users, the management and configuration of Linux software warehouse are optimized, and more optimized services are provided, further improving the basic service capability of Yum source software warehouse and Linux distribution. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0045] Figure 1 A method flow diagram for querying rpm package version and path in yum source is shown;

[0046] Figure 2 A RPM package information processing flow diagram in the method for querying rpm package version and path in yum source is shown;

[0047] Figure 3 A timing detection and updating json to deployment directory flow diagram in the method for querying rpm package version and path in yum source is shown;

[0048] Figure 4 A function diagram for realizing query interaction by html+nodejs in the method for querying rpm package version and path in yum source is shown;

[0049] Figure 5 A structure diagram of the method and system for querying rpm package version and path in yum source is shown. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the scope of protection of the present application.

[0051] The method and system for querying rpm package version and path in a yum source are provided in the embodiments of the present application. In processing such requirements, a feasible solution at present is to configure the repodata path under each directory in the repo file. However, this solution needs to determine the position of each repodata in the yum source and then configure each repodata to the repo file, and then the yum related command can be used to query the path and version information of the required RPM software. In the working process, users often encounter such query requirements. Using such a method increases the complexity of the overall working process and also limits the service capability of the Linux distribution. Therefore, from the perspective of the yum management party, a method is designed by using local data to sort and encapsulate the key information such as the package name, path and version of all RPM software packages in the yum source, and then a quick and convenient way is provided for users to query.

[0052] According to the above requirements, referring to Figures 1-3 The embodiments of the present application provide a method for querying rpm package version and path in a yum source, which comprises the following steps:

[0053] Step 1, determining the root directory of the yum source, obtaining the same directory as the yum source path in the local source, writing the queried information into a file A for storage, and cutting out the yum source path and storing it into a file B;

[0054] Step 2, obtaining all package name information based on the storage file A, which will be used as the key when querying and stored in a storage file C;

[0055] Step 3, obtaining all package complete version information based on the storage file A. The version information is the key information of the package, mainly composed of epoch: version-release. Considering that part of the complete package name ignores the epoch part, the version information needs to be extracted again and stored in a file D;

[0056] Step 4, based on the information obtained above and stored in the document, a json format file in the form of "package name-version-path" is obtained by splicing and formatting;

[0057] Step 5, to ensure the accuracy of data query, regularly detect and update the json file and synchronize to the service corresponding directory;

[0058] Step 6, provide a web interface to the front end user for display, so that the user only needs to input the package name and submit to obtain the json file data.

[0059] Specifically, the RPM package information processing part needs to sort out the package name, path and version corresponding information of the RPM package under the source directory: for the Yum source manager, there is the same server local source information as the Yum source data, according to the same local source information, the json data file is formed by sorting, filtering and combining.

[0060] It can be understood that by determining the root directory of the Yum source and writing the directory information in the local source with the same path as the Yum source into file A for storage, the basic directory structure of the Yum source can be conveniently obtained and used in subsequent updates and queries. By parsing the information in file A, the name of all packages can be obtained and stored in file C as the key for query, so that users can query and operate according to the package name. According to the information in file A, the complete version information of all packages can be extracted, including epoch, version and release. Since part of the complete package name may ignore the epoch part, the version information needs to be extracted again and stored in file D, so as to ensure the accuracy of the version information. In addition, based on the information stored before, a JSON format file meeting the requirements can be generated through splicing and formatting operations, which contains the information of "package name-version-path", so that front-end users can obtain the relevant version and path information according to the package name. In order to ensure the accuracy and timeliness of the data, the JSON file can be regularly detected and updated, and synchronized to the service corresponding directory. In this way, the data obtained by the user is always the latest. Finally, a web interface can be provided for front-end users, so that users only need to input the package name and submit to obtain the corresponding JSON file data, which can improve the user experience and enable them to conveniently query and browse the information of the package management system. Overall, this Yum source-based package management system has the characteristics of data accuracy, real-time updating and user-friendly, and can provide users with convenient and efficient package management functions.

[0061] Referring to Figures 2-4 As shown in the figure, in some embodiments of the present application, the query method and storage process in step 1 are as follows:

[0062] The complete path of all rpm package files in the same directory in the local source is queried by the find command in Linux and redirected to file A, and the same corresponding path as the yum source is cut out by awk by comparing the actual root path of the yum source and redirected to file B.

[0063] Specifically, in step 1: first, the RPM package information needs to be processed, and the root directory of the yum source in the local source is determined, which is usually the version number of the Linux distribution. After determining the directory, the complete path information of all rpm package files in the same directory in the local source is queried by the command find directory–name"*.rpm", and then stored in file A by redirection symbol ">". At the same time, the information after find query is passed to awk by using pipe symbol "|", because the rpm package path of the local source and the yum source comparison is usually inconsistent in the left part and completely consistent in the right part, and awk command is used to cut out the completely consistent path and direct it to file B.

[0064] Referring to Figures 2-4 As shown in the drawings, in some embodiments of the present application, the specific method for obtaining each package name information in step 2 is:

[0065] cat file A is used, then the pipe symbol "|" is used, and xargs is used to segment the parameters to pass to the rpm–q command, and the queryformat parameter is agreed to query the package name, so that the separate package name information without version number and architecture is obtained, and all the queried information is redirected to a new storage file C.

[0066] Specifically, in step 2: the information in B obtained in step 1 and the subsequent version information are the information that the user wants to query, and the information that needs to be submitted or input to query these information is the RPM package name. Because file A has been obtained, cat file A is used, then the pipe symbol "|" is used, and xargs is used to segment the parameters to pass to the rpm–q command, and the queryformat parameter is agreed to query the package name, so that the separate package name information without version number and architecture (for example, the complete package name lrzsz-0.12.20-36.el7.x86_64.rpm) is obtained (lrzsz is obtained), and all the queried information is redirected to a new storage file C.

[0067] Referring to Figures 2-4 As shown in the drawings, in some embodiments of the present application, the method for obtaining each package complete version information in step 3 is:

[0068] cat file A with pipe and xargs command to pass information in file A to rpm query command and print version information in epoch:version-release format using queryformat parameter, for version information with empty epoch itself use sed command to intercept, finally redirect version information to storage file D.

[0069] Specifically, in step 3: the version information is the most commonly required information of the RPM package by the user, because this information is the key identification information of the RPM package, based on which the remaining information can be found. The complete version information consists of epoch:version-release, considering that part of the complete package name ignores the epoch part, therefore the version information needs to be re-extracted. Similarly, cat file A with pipe and xargs command to pass information in file A to rpm query command and print version information in epoch:version-release format using queryformat parameter (since all rpm packages are stored in the local source, version information can be directly queried and obtained, which is also the advantage of integrating local source data), for version information with empty epoch itself use sed command to intercept, finally redirect version information to storage file D for subsequent combination;

[0070] Referring to Figures 2-4 In some embodiments of the present application, the way to splice and obtain the final json file in step 4 is as follows:

[0071] Use paste command to combine files C, D, and B by line to form file E, which is the key-values corresponding relationship of RPM package name, package version information and Yum source path where the package is located; and use jq command to process each group of corresponding relationship in file E as a json object and redirect it to json file F.

[0072] Specifically, in step 4: based on the input information “package name”, output information “version” and “path” that have been obtained, through combination and optimization, the json object file that is easy to read and retrieve is obtained. Use paste command to combine files C, D, and B by line to form file E, which is the key-values corresponding relationship of RPM package name, package version information and Yum source path where the package is located; then, use jq command to process each group of corresponding relationship in file E as a json object and redirect it to json file F. The reconstructed json format intercepts the following fragments, each json object has only three groups of key-value pairs, which is simple and structured enough, and the specific json structure is as follows:

[0073]

[0074] It can be understood that such a json structure has the following technical advantages:

[0075] Simplicity and efficiency: Each JSON object contains only the necessary three sets of key-value pairs, avoiding unnecessary data redundancy. This simplicity not only improves data readability, but also ensures network transmission efficiency, especially in bandwidth-limited environments;

[0076] Accurate user needs: The "name", "version" and "repo" key-value pairs in each object provide complete information about an RPM package. Users can determine whether an RPM package exists, its version number, and where it can be found by only looking at these core fields;

[0077] Provide solutions to key problems: This format provides a simple solution to the main questions of users, namely the existence of RPM packages, version information and repo path. This direct solution helps users make quick and accurate decisions without getting bogged down in complex data processing and analysis;

[0078] Easy to maintain and extend: The clear structure of each object makes subsequent maintenance and updates intuitive. If more information needs to be added in the future, it can be easily extended in the existing structure without disrupting the overall data format;

[0079] Emphasize developer friendliness: Using clear and concise key names improves data readability and understandability, helping developers integrate these data into applications more quickly.

[0080] Referring to Figures 2-4 In some embodiments of the present application, the method of timing updating the json file in step 5 is:

[0081] Integrate the process tool of generating json file F into the local source server's timing task crontab. Before executing the process of generating json, calculate the MD5 value of file A to determine whether all processes from step 1 to step 5 are needed. If the MD5 value of the new file A is the same as the old MD5 value, it means that the Yum source data has not changed, and the json file does not need to be updated.

[0082] It can be understood that after updating the new json file, the json file is updated to the html file in the same directory in step 2 using the cp / scp command, which completes the update of the json file and maintains the data timeliness of the query tool.

[0083] Referring to Figures 2-4As shown, in some embodiments of the present application, the use mode shown to the user in step 6 is:

[0084] A simple static search box containing a search input bar and a clickable search button is generated by html, and then associated with a custom function G in javascript through an onclick event to achieve interaction, so that when the "search" button is clicked, the javascript triggers the initial page number and package name to the backend nodejs, the backend nodejs queries the json file through the package name and the current page number and returns only the current page content and the total count to the function G, G passes the json and the total count to the function H, H displays the data of the current page according to the total number and the json to the front end, and judges whether the page number click event occurs, if so, the function G is called to query the data of the page.

[0085] It can be understood that this method will only display the current page data to the front end even if it matches more than ten thousand data in extreme cases, preventing front-end display overflow and ensuring data security.

[0086] On the other hand, referring to Figure 5 As shown, the present embodiment also proposes a system for querying rpm package versions and paths in yum sources, comprising:

[0087] An information processing module is used to determine the root directory of the Yum source, and obtain the directory in the local source that is the same as the Yum source path, write the query result into file A, and cut out the Yum source path and store it in file B; the information processing module is also used to obtain information of all package names based on file A and store it in file C as key information for querying; the information processing module is also used to obtain complete version information of all packages based on file A and store it in file D, the version information consists of epoch, version-release; according to the stored information, splice and format into a JSON file in the form of "package name-version-path";

[0088] An automatic detection module is used to periodically detect and update the JSON file, and synchronize it to the corresponding service directory;

[0089] An interactive module is used to provide a Web interface for users to display, and users can obtain JSON file data by only inputting the package name and submitting.

[0090] In some embodiments of the present application, the query mode and storage process of the information processing module are:

[0091] The complete paths of all rpm package files in the same directory in the local source are queried by the find command in Linux and redirected to file A, and the same corresponding paths as the Yum source are cut out by using awk to compare the actual root path of the Yum source and redirected to file B;

[0092] The specific method of the information processing module for obtaining each package name information is:

[0093] The cat file A is used, then the pipe symbol “|” is used, xargs is used to segment the parameters and pass them to the rpm–q command, and the queryformat parameter is used to query the package name, so that the single package name without version number and architecture information is obtained, and all the queried information is redirected to a new storage file C;

[0094] The method of the information processing module for obtaining the complete version information of each package is:

[0095] The cat file A is used, then the pipe symbol and the xargs command are used to pass the information in file A to the rpm query command, the queryformat parameter is used to print the epoch:version-release format version information, and the sed command is used to intercept the version information for which the epoch itself is empty, and finally the version information is redirected to a storage file D;

[0096] The method of the information processing module for splicing and obtaining the final json file is:

[0097] The paste command is used to combine files C, D, and B into file E, and file E is the key-values corresponding relationship of the RPM package name, package version information and Yum source path; and the jq command is used to process each corresponding relationship in file E into a json object and redirect it to json file F.

[0098] In some embodiments of the present application, the method of the automatic detection module for updating the json file is:

[0099] The process tool for generating json file F is integrated into the local source server's cron task crontab, before executing the process of generating json, whether all the processes in the information processing module need to be processed is determined by calculating the MD5 value of file A, if the MD5 value of the new file A is the same as the old MD5 value, it means that the Yum source data has not changed, and the json file does not need to be updated; after updating the new json file, the cp / scp command is used to update the json file to the html file in the same directory of the information processing module, so that the updating of the json file is completed and the data timeliness of the query tool is maintained;

[0100] The use mode displayed to the user by the automatic detection module is as follows:

[0101] A simple static search box containing a search input box and a clickable search button is generated through html, and is associated to a custom function G in javascript through an onclick event to realize interaction, so that when the "search" button is clicked, the javascript triggers the initial page number and package name to be transmitted to the backend nodejs, the backend nodejs queries the json file through the package name and the current page number and returns only the current page content and the total count to the function G, the G transmits the json and the total count to the function H, the H displays the data of the current page according to the total count and the json to the front end, and judges whether the page number click event occurs, if so, the function G is called to query the data of the page.

[0102] At present, for the query of unknown RPM package information in the Yum source, a feasible method needs to be divided into two steps, first, the location paths of repodata files in several to tens of directories in Yum need to be determined, then the paths are configured in the repo file in the / etc / yum.repos.d / directory, and then the information required by the query is queried by using the yuminfo command. It can be seen that this method will consume a lot of time, and the process is more complicated, and if the Yum source directory structure is changed due to official adjustment, the configuration process needs to be performed again each time.

[0103] In summary, by applying the above technical solutions, the method and system for querying the rpm package version and path in the yum source have the following technical effects:

[0104] 1. Simplify the work flow of users and providers. Starting from the Yum source official, the information of all RPM packages in the local source is processed and sorted, the key-value corresponding relationship is extracted, and the relationship information is stored as a json object, and the timeliness of the queried data is ensured through regular updating, so that only one deployment is needed, and manual maintenance is not needed. Through html+nodejs, the entrance of the RPM package query is provided to the Linux distribution user in the form of a webpage, and the user only needs to open the query webpage to input the RPM package name in the search box to query and obtain the result. Compared with manual configuration of the repo file, this method is more convenient, and because the data comes from the official, the accuracy of the result is ensured, and omission is avoided.

[0105] 2. Improve the basic service capability of Linux distribution. By further sorting and processing the local synchronized data of the Yum source and providing it to the user, the management configuration of the Linux software warehouse is optimized, a more optimized service is provided, and the basic service capability of the Yum source software warehouse and the Linux distribution is further improved.

[0106] Those skilled in the art can clearly understand the present application through the description of the above embodiments. The present application can be implemented by hardware or by means of software and necessary general hardware platform. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a U disk, a mobile hard disk, etc.), and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in various embodiments of the present application.

[0107] Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing examples, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing examples, or make equivalent replacement for some technical features; and these modifications or replacements do not drive the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for querying the version and path of an RPM package in a yum repository, characterized in that, include: Step 1: Determine the root directory of the yum repository and obtain the directory in the local repository that has the same path as the yum repository. Write the query results to file A and cut out the yum repository path and save it to file B. Step 2: Obtain information on all package names from file A and store it in file C as key information for querying; Step 3: Obtain the complete version information of all packages based on file A and store it in file D. The version information consists of epoch and version-release. Step 4: Based on the stored information, concatenate and format it into a JSON file in the format of "package name-version-path"; Step 5: Regularly check and update the JSON file, and synchronize it to the corresponding service directory; Step 6: Provide a web interface for users to view. Users only need to enter the package name and submit to obtain the JSON file data. The method for obtaining the complete version information of each package in step 3 is as follows: The information in file A is passed to the rpm query command by using the cat command with pipes and the xargs command. The queryformat parameter is used to print the version information in the format of epoch:version-release. For version information with an empty epoch, the sed command is used to truncate it. Finally, the version information is redirected and stored in storage file D. The method for concatenating and obtaining the final JSON file in step 4 is as follows: Use the paste command to combine files C, D, and B line by line into file E. File E contains the key-value pairs of the rpm package name, package version information, and the yum source path where the package is located. Then, use the jq command to process each pair of correspondences in file E into a JSON object and redirect it to be stored in JSON file F; The usage method shown to the user in step 6 is as follows: A simple static search box with a search input field and a clickable search button is generated using HTML. An onclick event is used to connect to a custom JavaScript function G for interactivity. When the "Search" button is clicked, JavaScript sends the initial page number and package name to the backend Node.js. The backend Node.js uses the package name and current page number to query a JSON file and returns only the current page content and the total count to function G. G then passes the JSON and the total count to function H. H displays the current page's data paginated on the frontend based on the total count and the JSON, and checks if a page click event has occurred. If so, it calls function G to query the data for that page.

2. The method for querying the version and path of RPM packages in a yum repository as described in claim 1, characterized in that, The query method and storage process in step 1 are as follows: The `find` command in Linux is used to find the full paths of all RPM package files in the same directory in the local repository and redirect them to file A. Then, by comparing the actual root path of the yum repository, awk is used to trim the path to the same path as the yum repository and redirect it to file B.

3. The method for querying the version and path of RPM packages in a yum repository as described in claim 1, characterized in that, The specific method for obtaining each package name information in step 2 is as follows: Use the cat command to access file A, then use the pipe symbol "|" and xargs to pass the parameters in segments to the rpm -q command. The query format parameter specifies the package name to be queried, and the result is a separate file without version number and architecture information. All the retrieved information is then redirected and stored in a new storage file C.

4. The method for querying the version and path of rpm packages in a yum repository as described in claim 1, characterized in that, The method for periodically updating the JSON file in step 5 is as follows: Integrate a workflow tool for generating JSON file F into the scheduled task crontab of the local source server. Before executing the JSON generation process, determine whether all processes from step 1 to step 5 need to be performed by calculating the MD5 value of file A. If the MD5 value of the new file A is the same as the old MD5 value, it means that the yum source data has not changed and there is no need to update the JSON file. After updating and generating a new JSON file, use the cp / scp command to periodically update the JSON file to the same directory as the HTML file in step 2.

5. A system for querying the version and path of RPM packages in a yum repository, characterized in that, include: The information processing module is used to determine the root directory of the yum repository, obtain the directory in the local repository that has the same path as the yum repository, write the query results to file A, and trim the yum repository path and store it in file B. The information processing module is also used to obtain information on all package names based on file A and store it in file C as key information during the query. The information processing module is also used to obtain complete version information of all packages based on file A and store it in file D. The version information consists of epoch and version-release. Based on the stored information, it is concatenated and formatted into a JSON file in the form of "package name-version-path". The automatic detection module periodically detects and updates the JSON file, and synchronizes it to the corresponding service directory; The interactive module provides a web interface for users to view. Users only need to enter the package name and submit to obtain JSON file data. The method by which the information processing module obtains the complete version information of each package is as follows: The information in file A is passed to the rpm query command by using the cat command with pipes and the xargs command. The queryformat parameter is used to print the version information in the format of epoch:version-release. For version information with an empty epoch, the sed command is used to truncate it. Finally, the version information is redirected and stored in storage file D. The information processing module concatenates and obtains the final JSON file in the following way: Use the paste command to combine files C, D, and B line by line into file E. File E contains the key-value pairs of the rpm package name, package version information, and the yum source path where the package is located. Then, use the jq command to process each pair of correspondences in file E into a JSON object and redirect it to be stored in JSON file F; The automatic detection module is presented to the user in the following way: A simple static search box with a search input field and a clickable search button is generated using HTML. An onclick event is used to link it to a custom JavaScript function G for interactivity. When the "Search" button is clicked, JavaScript sends the initial page number and package name to the backend Node.js. The backend Node.js uses the package name and current page number to query a JSON file and returns only the current page content and the total count to function G. Function G then passes the JSON and the total count to function H. H displays the current page's data paginated on the frontend based on the total count and the JSON, and checks if a page click event has occurred. If so, it calls function G to query the data for that page.

6. The system for querying the version and path of RPM packages in a yum repository as described in claim 5, characterized in that, The query method and storage process of the information processing module are as follows: The full paths of all RPM package files in the same directory in the local repository are retrieved using the find command in Linux and redirected to file A. The actual root path of the yum repository is compared with the actual root path of the yum repository and the corresponding path is trimmed using awk and redirected to file B. The specific method by which the information processing module obtains each package name information is as follows: Use the cat command to access file A, then use the pipe symbol "|" and xargs to pass the parameters in segments to the rpm -q command. The query format parameter specifies the package name to be queried, and the result is a separate file without version number and architecture information. All the retrieved information is then redirected and stored in a new storage file C.

7. The system for querying the version and path of RPM packages in a yum repository as described in claim 6, characterized in that, The method by which the automatic detection module updates the JSON file periodically is as follows: Integrate a workflow tool for generating JSON file F into the scheduled task crontab of the local source server. Before executing the JSON generation workflow, determine whether all workflows in the information processing module need to be performed by calculating the MD5 value of file A. If the MD5 value of the new file A is the same as the old MD5 value, it means that the yum source data has not changed and there is no need to update the JSON file. After the new JSON file is generated, the cp / scp command is used to periodically update the JSON file to the same directory as the HTML file in the information processing module. This completes the update of the JSON file and maintains the timeliness of the query tool's data.

Images