Patch file processing device and patch file processing method

Abstract

To provide a device and a method capable of efficiently applying necessary patch files.SOLUTION: The patch file processing device comprises a specification unit, a determination unit, and a patch application processing unit. The patch file processing device applies patch files to software used by an information processing device. The specification unit identifies a first software module usable by the information processing device and a first package to which the first software module belongs, based on a safe list where software modules usable by the information processing device are registered. The determination unit determines whether the target file to which the candidate patch file should be applied corresponds to the first package based on the description of the candidate patch file. The patch application processing unit applies the candidate patch file to the first software module when the target file corresponds to the first package.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for applying a patch file to software. [Background technology]

[0002] In an information processing device that uses open source software (OSS), patch files may be applied to modify or extend source code. However, determining whether or not to apply every patch file places a heavy burden on the user or administrator. For this reason, a method has been proposed that determines whether or not to apply a modification (i.e., a patch file) depending on the execution status of a program (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2015-197841 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the above-mentioned method, the necessity of applying a patch file is determined based on the number of times the program is executed, etc., so there is a risk that a patch file necessary for fixing a defect, etc. will not be applied. In addition, the overhead and memory resource consumption for writing the software execution history increases.

[0005] An object of one aspect of the present invention is to provide an apparatus and method that can efficiently apply required patch files. [Means for solving the problem]

[0006] A patch file processing device according to one aspect of the present invention applies a patch file to software used by an information processing device. The patch file processing device includes an identification unit that identifies a first software module usable by the information processing device and a first package to which the first software module belongs, based on a safe list in which software modules usable by the information processing device are registered, a determination unit that determines, based on a description of the candidate patch file, whether a target file to which the candidate patch file should be applied corresponds to the first package, and a patch application processing unit that applies the candidate patch file to the first software module if the target file corresponds to the first package. [Effects of the Invention]

[0007] According to the above-described aspect, the necessary patch files can be applied efficiently. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating an example of a patch file processing device according to an embodiment of the present invention. [Figure 2] FIG. 10 is a diagram illustrating an example of a patch file. [Figure 3] FIG. 10 is a diagram illustrating an example of the configuration and implementation of a safe list. [Figure 4] 10A and 10B are diagrams illustrating an example of the configuration of a package list and an example of an embodiment of the package list; [Figure 5] 1 is a flowchart illustrating an example of a method for creating a package list. [Figure 6] 10A and 10B are diagrams illustrating an example of the configuration of a list of patch files to be applied and an example of an embodiment of the list. [Figure 7] 10 is a flowchart illustrating an example of a method for creating a list of patch files to be applied. [Figure 8] FIG. 10 is a diagram illustrating an example of a list of files in a package. [Figure 9] FIG. 10 is a diagram illustrating an example of a makefile. [Figure 10] FIG. 10 is a diagram illustrating an example of a procedure for creating a list of patch files to be applied. [Figure 11] 10 is a flowchart illustrating an example of processing by a patch application processing unit. [Figure 12] FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device or a patch file processing device. DETAILED DESCRIPTION OF THE INVENTION

[0009] FIG. 1 shows an example of a patch file processing device according to an embodiment of the present invention. A patch file processing device 10 according to the embodiment of the present invention is implemented in an information processing device 1A. The patch file processing device 10 applies a patch file to software used by an information processing device 1B. In this example, the software used by the information processing device 1B (i.e., the software to which the patch file processing device 10 applies a patch file) is open source software (OSS) such as Linux (registered trademark).

[0010] The information processing device 1A and the information processing device 1B provide a development environment and an execution environment, respectively. The information processing device 1A and the information processing device 1B may be realized by one computer or by multiple physically separate computers.

[0011] The information processing device 1B includes a safe list 21. Software that the information processing device 1B can use is registered in the safe list 21. That is, when the information processing device 1B executes software, it checks whether the software is registered in the safe list 21. If the software is registered in the safe list 21, the information processing device 1B executes the software. On the other hand, if the software is not registered in the safe list 21, the information processing device 1B cannot execute the software.

[0012] The software used by the information processing device 1B is open source software (OSS), and patch files are sometimes created to modify or extend the source code. However, determining whether or not each patch file needs to be applied places a heavy burden on the user or administrator. For this reason, the patch file processing device 10 automatically extracts and applies patch files that are valid for the information processing device 1B from among the multiple patch files that have been created.

[0013] The patch file processing device 10 includes a package list creation unit 11, an application target patch file list creation unit 12, and a patch application processing unit 13. Note that the patch file processing device 10 may further include other functions not shown in FIG.

[0014] The information processing device 1A acquires the safelist 21 from the information processing device 1B. The acquired safelist 21 is stored in a memory accessible by the patch file processing device 10. The information processing device 1A also collects patch files 22 related to software that can be used by the information processing device 1B. At this time, the information processing device 1A may acquire the patch files 22 from a pre-specified site. The collected patch files 22 are stored in a memory accessible by the patch file processing device 10. The patch file processing device 10 then references the safelist 21 provided in the information processing device 1B, extracts patch files that are valid for the information processing device 1B from the collected patch files 22, and applies them. Therefore, the collected patch files 22 are candidate patch files to be applied at this point.

[0015] The package list creation unit 11 creates a package list 31 by identifying software modules that can be used by the information processing device 1B and the software packages to which those software modules belong, based on the safe list 21. Therefore, the package list 31 registers the software packages to which the software modules registered in the safe list 21 belong. The package list creation unit 11 is an example of an identification unit that identifies software modules that can be used by the information processing device and the software packages to which those software modules belong, based on the safe list.

[0016] A software package may include, but is not limited to, an executable file, which is the main body of the software, and program files such as libraries and modules used by the executable file. A software package may also be a commercially available software product. Furthermore, a software package can be modified, customized, or have additional functions added by applying patch files. In the following description, a software package may be simply referred to as a "package."

[0017] The patch file list creator 12 refers to the package list 31 and determines whether each patch file 22 is a patch file to be applied. The patch files to be applied are then registered in the patch file list 32. Therefore, the patch file list creator 12 is an example of a determination unit that determines whether to apply a candidate patch file to software that can be used by the information processing device 1B.

[0018] The patch application processing unit 13 applies the patch files 22 registered in the patch file list 32 to the corresponding software.

[0019] 2 shows an example of the patch file 22. In this embodiment, the patch file 22 represents the differences between the old file and the new file. The symbols in the patch file shown in FIG. 2 have the following meanings:

[0020] "---" represents the path name of the old file. In the example shown in Figure 2, "a / procps / top / top.c" represents the path name of the old file. "+++" represents the path name of the new file. In the example shown in Figure 2, "b / procps / top / top.c" represents the path name of the old file.

[0021] "@@" indicates the start line and range of the change. "-" indicates the deletion. "+" indicates the addition. Lines without a symbol at the beginning indicate the specified range immediately before and after the change (three lines in Figure 2).

[0022] FIG. 3A shows an example of the configuration of the safelist 21. The safelist 21 is composed of a path name, a hash value, and a program type. The path name indicates the location where a program module usable by the information processing device 1B is stored. In other words, the path name identifies a software module usable by the information processing device 1B. The hash value indicates the hash value of the software module stored in the location indicated by the corresponding path name. Note that the hash value can be used, for example, to check whether data has been corrupted or tampered with. The program type indicates the type of software module stored in the location indicated by the corresponding path name. In this embodiment, the program type indicates whether the software module stored in the location indicated by the corresponding path name is an executable program or a shared library.

[0023] FIG. 3B shows an example of the safelist 21. In this example, the top command is registered as an executable program that can be used by the information processing device 1B. The top command can display the status of the Linux system and running processes in real time. Also, libc.so.6 is registered as a shared library that can be used by the information processing device 1B. The safelist 21 is created, for example, by a user or administrator of the information processing devices 1A and 1B. Alternatively, the safelist 21 may be created automatically by learning the execution status of the information processing device 1B.

[0024] 4A shows an example of the configuration of the package list 31. The package list 31 is composed of a package name and a path name. The path name is the same as the path name registered in the safe list 21. The package name indicates the package to which the program (executable module) stored in the location indicated by the corresponding path name belongs. In other words, the package list 31 registers, for each software module registered in the safe list 21, the package to which that software module belongs.

[0025] FIG. 4B shows an example of the package list 31. In this example, a package name is registered for each of the two path names ( / bin / top, / lib / libc.so.6) registered in the safe list 21 shown in FIG. 3B. Specifically, "procps" is registered as the package to which the top command belongs. Furthermore, "glibc" is registered as the package to which the shared library libc.so.6 belongs. Here, the software modules corresponding to each path name are software that can be used by the information processing device 1B. Therefore, the package list 31 registers packages to which software modules that can be used by the information processing device 1B belong.

[0026] 5 is a flowchart showing an example of a method for creating a package list 31. The processing of this flowchart is executed by the package list creation unit 11. It is assumed that the patch file processing device 10 has acquired the safe list 21 from the information processing device 1B. It is also assumed that one or more patch files 22 are provided to the patch file processing device 10, as shown in FIG.

[0027] In S1, the package list creation unit 11 acquires one registered module from the safe list 21. The registered module refers to a software module stored in a location indicated by a path name registered in the safe list 21.

[0028] In S2, the package list creation unit 11 identifies the package to which the registered module acquired from the safe list 21 belongs. At this time, the package list creation unit 11 may identify the package to which the registered module belongs by using, for example, a command for managing packages (such as the dpkg command in the case of a Debian-based package).

[0029] In S3, the package list creation unit 11 associates the name of the identified package with the path name and registers it in the package list 31. That is, the path name indicating the storage location of the registered module acquired in S1 and the package name of the package to which the registered module belongs are registered in the package list 31 in association with each other.

[0030] In S4, the package list creation unit 11 checks whether or not there are any registered modules remaining in the safe list 21 for which the processes of S1 to S3 have not been executed. If there are any registered modules remaining for which the processes of S1 to S3 have not been executed, the package list creation unit 11 updates the target position in the safe list 21 in S5. Thereafter, the process of the package list creation unit 11 returns to S1. As a result, the next registered module is extracted, and the processes of S1 to S3 are executed. That is, the processes of S1 to S3 are executed for each software module registered in the safe list 21, and the package to which that software module belongs is identified and registered in the package list 31.

[0031] An example is shown below. Here, it is assumed that safe list 21 shown in Fig. 3B has been prepared. Then, package list creation unit 11 performs the processes of S1 to S3 in Fig. 5 on the first record in safe list 21.

[0032] This record has the path name " / bin / top" registered. Therefore, the software module registered in this record is the top command. That is, in S1, the package list creation unit 11 acquires "top." Next, in S2, the package list creation unit 11 identifies the package to which "top" belongs. In this example, it is identified that the package to which "top" belongs is "procps."

[0033] Thereafter, in S3, the package list creation unit 11 registers the package name identified in S2 in association with the path name noted in S1 in the package list 31. As a result, as shown in Fig. 4B, the package name "procps" is registered in association with the path name " / bin / top." That is, the package name "procps" corresponding to the software module "top" registered in the safe list 21 is registered in the package list 31.

[0034] 6A shows an example of the configuration of the list of patch files to be applied 32. The list of patch files to be applied 32 is composed of patch file names and destination file path names. The patch file name indicates the patch file to be applied to the corresponding software module by the patch file processing device 10. The destination file path name identifies the path where the file to which the patch file is applied is saved.

[0035] 6B shows an example of the list of patch files to be applied 32. In this example, the patch file "top.patch" is applied to the file (i.e., top.c) stored in the file path " / usr / src / procps / top / top.c." The patch file "malloc.patch" is applied to the file (i.e., malloc.c) stored in the file path " / usr / src / glibc / malloc / malloc.c."

[0036] 7 is a flowchart showing an example of a method for creating the list of patch files to be applied 32. The process of this flowchart is executed by the list creator 12 for creating patch files to be applied.

[0037] For each package, a file list is created in advance that shows the file structure within the package. This file list can be used when searching for file names within the package. An example of a file list is shown in Figure 8. Here, the files included in the package Procps are displayed in a tree structure. The " / usr / src / procps" on the first line corresponds to the path where this package is saved. In other words, in this example, the package source is saved in / usr / src. One or more files are placed in each directory. For example, files such as top.c, top.h, top_nls.c, and top_nls.h are placed in the top directory.

[0038] A makefile is also created for each package. The makefile is a file that describes installation procedures, file generation procedures, the relationships between files that make up the program, compilation procedures, etc., and is used by the make command. Therefore, the software modules to be executed by the information processing device 1B are described as input files in the makefile. An example of the makefile is shown in FIG. 9.

[0039] When creating the patch file list 32 to be applied, one or more patch files 22 are provided to the patch file processing device 10. At this time, it is assumed that the package list creation unit 11 has created a package list 31 (for example, the package list shown in FIG. 4B).

[0040] In S11, the patch file list creator 12 selects one patch file 22 from among the multiple patch files to be applied, and obtains the path name of the target file to which that patch file 22 should be applied. The path name can be obtained by referencing the contents of the patch file 22. For example, in the patch file (top.patch) 22 shown in FIG. 2, the path name of the new file is written on the second line. Therefore, in this case, "b / procps / top / top.c" is obtained as the path name of the target file to which patch file 22 should be applied.

[0041] In S12, the patch file list creator 12 selects one record in the package list 31 and obtains the package name recorded in that record. For example, when the first record in the package list 31 shown in FIG. 4B is selected, the package name "procps" is obtained.

[0042] In S13 and S14, the patch file list creator 12 determines whether the path name obtained in S11 includes the package name obtained in S12. That is, it determines whether the path name of the target file to which the patch file 22 selected in S11 should be applied includes the package name registered in the record selected from the package list 31 in S12. In the above case, the path name "b / procps / top / top.c" includes the package name "procps."

[0043] If the path name includes a package name (S14: Yes), the patch file list creator 12 searches in S15 and S16 to determine whether the file name in the path name selected in S11 exists in the file list of the corresponding package. For example, when the path name "b / procps / top / top.c" described above is acquired, "top.c" is obtained as the file name of the target file to which the patch file 22 should be applied. Also, it is assumed that the file list shown in FIG. 8 has been prepared. In this case, it is determined that "top.c" exists in this file list.

[0044] If the file name exists in the file list (S16: Yes), the patch file list creator 12 determines in S17 and S18 whether a target (execution module) is described as an input file in the makefile of the package represented by the package name acquired in S12. The target is a software module to which the patch file 22 selected in S11 should be applied, and is described in the path name registered in the record selected from the package list 31 in S12. For example, when the first record in the package list 31 shown in FIG. 4B is selected, the path name registered in that record is " / bin / top," and the target execution module is "top." Here, it is assumed that the makefile shown in FIG. 9 has been created. In this case, it is determined that the target (top) is described as an input file in that makefile.

[0045] When a target (execution module) is described as an input file in the makefile (S18: Yes), in S19, the patch file list creation unit 12 registers the patch file name and the destination file path name in the patch file list 32. This patch file name represents the name of the patch file 22 selected in S11. The destination file path name is obtained by referencing the file list of the package that includes the target file to which the patch file 22 selected in S11 should be applied. After this, the processing of the patch file list creation unit 12 proceeds to S22.

[0046] If the pathname does not include a package name (S14: No), if the file name does not exist in the file list (S16: No), or if the target is not described as an input file in the makefile (S18: No), in S20 to S21, the patch file list creation unit 12 selects the next record in the package list 31. The patch file list creation unit 12 then proceeds to S12. That is, the patch file list creation unit 12 executes S12 to S18 for each record in the package list 31. If the pathname includes a package name (S14: Yes), the file name exists in the file list (S16: Yes), and the target is described as an input file (S18: No), the patch file list creation unit 12 registers the patch file name and the destination file path name in the patch file list 32. Once S12 to S18 have been completed for all records in the package list 31, the patch file list creation unit 12 proceeds to S22.

[0047] In S22, the to-be-applied patch file list creator 12 checks whether any patch files remain that have not been processed through S11 to S21. If any patch files remain that have not been processed through S11 to S21, the to-be-applied patch file list creator 12 selects one of these unprocessed patch files in S23. After this, the to-be-applied patch file list creator 12 returns to S11. That is, the to-be-applied patch file list creator 12 performs the processes of S11 to S21 for each patch file 22 that has been given to it.

[0048] In this way, the patch file to be applied list creator 12 executes the processes of S11 to S21 for each patch file. As a result, when a patch file that satisfies the three conditions shown in S13 to S18 is detected, the patch file to be applied list creator 12 registers the file name of the patch file and the destination file path name indicating the storage location of the file to which the patch file should be applied in the patch file to be applied list 32. In this way, the patch file to be applied list 32 is created. As an example, the patch file to be applied list 32 shown in FIG. 6B is obtained.

[0049] FIG. 10 shows an example of the procedure for creating the list of patch files to be applied 32. In this embodiment, a patch file 22a is provided to the patch file processing device 10 as a patch file candidate for application. The file name of the patch file 22a is "top.patch." In addition, a package list 31a is created by the package list creation unit 11. The package Procps includes a file list 41. Alternatively, the file list 41 is created for the package Procps. Furthermore, a makefile 42 is created for the package Procps.

[0050] In this case, in S11, the patch file list creator 12 obtains the path name "b / procps / top / top.c" of the file to which the patch file should be applied from the patch file 22a.

[0051] In steps S12 to S14, the patch file list creator 12 obtains the package name "procps" from the first record in the package list 31a. This package name is included in the path name obtained from the patch file 22a. Therefore, the process of the patch file list creator 12 proceeds to step S15.

[0052] In S15 and S16, the file name "top.c" that appears in the path name obtained from the patch file 22a is present in the file list 41 of the package Procps. Therefore, the process of the patch file list creator 12 to be applied proceeds to S17.

[0053] In S17 and S18, the patch file list creator 12 determines whether a target (execution module) is described as an input file in the makefile 42 of the package Procps. Here, the target is a software module to which the patch file 22a should be applied, and is "top" described in the path name registered in the first record of the package list 31a. If so, it is determined that this target (execution module) is described as an input file in the makefile 42.

[0054] 10, the three conditions shown in S13 to S18 are satisfied. In this case, path information indicating the actual storage location of the file to which patch file 22a is applied is generated. Specifically, by searching the directory of target module "top" in file list 41 of package Procps, the actual path name of the file to which patch file 22a is applied, " / usr / src / procps / top / top.c," is obtained. Then, patch file list creator 12 registers this file path name in patch file list 32 in association with the file name of patch file 22a.

[0055] In order to satisfy the conditions shown in S13 to S14, it is necessary that the package name registered in the package list 31 is included in the path name obtained from the patch file 22. Here, the package name registered in the package list 31 represents the name of the package corresponding to the software module registered in the safe list 21. Therefore, the case in which the conditions shown in S13 to S14 are satisfied is obtained when the target file specified in the patch file 22 is a module registered in the safe list 21. In other words, when the target file specified in the patch file 22 is not a software module registered in the safe list 21, the conditions shown in S13 to S14 are not satisfied, and therefore the path of that file is not registered in the target patch file list 32.

[0056] 11 is a flowchart showing an example of processing by the patch application processing unit 13. This processing is executed after the patch file list creator 12 creates the patch file list 32. It is also assumed that one or more patch files 22 have been provided to the patch file processing device 10.

[0057] In S31, the patch application processing unit 13 selects one record in the patch file list 32 to be applied, and acquires the patch file name registered in that record. In S32, the patch application processing unit 13 acquires the path name of the destination file registered in the record selected in S31. In S33, the patch application processing unit 13 applies the patch file represented by the patch file name acquired in S31 to the file stored in the location represented by the path name acquired in S32. At this time, a patch command predetermined by the patch application processing unit 13 is executed. The destination file is a source file written in source code, and the source file is updated in accordance with the patch file.

[0058] In S34, the patch application processing unit 13 checks whether there are any records remaining in the patch file to be applied list 32 for which the processes of S31 to S33 have not been executed. If there are any records remaining for which the processes of S31 to S33 have not been executed, the patch application processing unit 13 specifies the next record in S35, and then returns to S31. That is, the patch application processing unit 13 executes the processes of S31 to S33 for each patch file registered in the patch file to be applied list 32. As a result, each patch file provided to the patch file processing device 10 is applied to the corresponding software module.

[0059] After that, the information processing device 1A builds the software module (source file) to which the patch file 22 has been applied. As a result, a software module (executable program) to which the patch file has been applied is obtained. The software module to which the patch file has been applied may be a library. The information processing device 1A then provides the software module to which the patch file has been applied to the information processing device 1B. Alternatively, the software module stored in the information processing device 1B is updated to a software module to which the patch file has been applied by the information processing device 1A.

[0060] As described above, in an embodiment of the present invention, when the application destination of a patch file is registered in the safe list of the information processing device, the patch file is registered in the list of patch files to be applied 32 and applied to the corresponding software module. In other words, a patch file whose application destination is not registered in the safe list is not registered in the list of patch files to be applied 32, and application processing is not executed. Therefore, since there is no need to determine whether each patch file needs to be applied, the burden on the user or administrator of the information processing device is reduced. Furthermore, unlike the method related to Patent Document 1 described above, there is no need to manage the number of times each program is executed, and therefore the overhead or memory resource consumption for determining whether a patch file needs to be applied is reduced.

[0061] An information processing device that operates in accordance with the safe list can only use software modules that are registered on the safe list. Therefore, it is sufficient to apply patch files to software modules that are registered on the safe list. Even if patch files are not applied to software modules that are not registered on the safe list, no problems will occur. Therefore, the necessary patch files can be applied efficiently.

[0062] In the example shown in FIGS. 7 to 10, a candidate patch file is applied to a corresponding software module when three conditions are met. That is, the candidate patch file is applied to a corresponding software module when the path name includes a package name (S14: Yes), the file name exists in the file list (S16: Yes), and the target is described as an input file (S18: No). However, the embodiment of the present invention is not limited to this procedure. That is, the candidate patch file may be applied to a corresponding software module when any one or any two of the above three conditions are met. For example, the patch file processing device 10 may apply the candidate patch file to a corresponding software module when the path name identifying the file to be applied described in the candidate patch file includes the name of a package to which a software module registered on the safe list 21 belongs.

[0063] <Hardware configuration> 12 shows an example of the hardware configuration of the information processing device 1A (or the patch file processing device 10). The information processing device 1A is realized by a computer system 100 including a processor 101, a memory 102, a storage device 103, an input / output device 104, a recording medium reader 105, and a communication interface 106.

[0064] The processor 101 executes a patch file application program stored in the storage device 103. When the processor 101 executes the patch file application program, the functions of the package list creation unit 11, the patch file list creation unit 12, and the patch application processing unit 13 shown in FIG. 1 are provided. The memory 102 is used as a work area for the processor 101. The storage device 103 stores the patch file application program and other programs. The safe list 21, the patch file 22, and the source file are temporarily stored in the memory 102 or the storage device 103.

[0065] The input / output device 104 may include input devices such as a keyboard, a mouse, a touch panel, and a microphone. The input / output device 104 may also include output devices such as a display device and a speaker. The recording medium reader 105 can acquire data and information recorded on the recording medium 110. The recording medium 110 is a removable recording medium that can be attached to or detached from the computer system 100. The recording medium 110 may be implemented, for example, as a semiconductor memory, a medium that records signals optically, or a medium that records signals magnetically. The patch file application program may be provided to the computer system 100 from the recording medium 110. The communication interface 106 provides a function for connecting to a network. When the patch file application program is stored in the program server 120, the computer system 100 may acquire the patch file application program from the program server 120. [Explanation of symbols]

[0066] 1A, 1B Information processing equipment 10 Patch file processing device 11 Package List Creation Department 12 Patch file list creation section 13 Patch application processing section 21 Safelist 22(22a) patch file 31(31a) Package List 32 List of patch files to be applied 41 File List 42 makefile

Claims

1. A patch file processing device that applies a patch file to software used by an information processing device, an identification unit that identifies a first software module that can be used by the information processing device and a first package to which the first software module belongs, based on a safe list in which software modules that can be used by the information processing device are registered; a determination unit that determines, based on a description of the candidate patch file, whether the target file to which the candidate patch file is to be applied corresponds to the first package; a patch application processing unit that applies the application candidate patch file to the first software module when the target file corresponds to the first package; A patch file processing device comprising:

2. The determination unit obtain a path name that identifies the target file, which is written in the application candidate patch file; When the path name includes information that identifies the first package, it is determined that the target file corresponds to the first package.

2. The patch file processing device according to claim 1, wherein the patch file processing device is a device for processing a patch file.

3. The determination unit refers to a file list representing the file configuration in the first package, and determines that the target file corresponds to the first package when the file name in the path name exists in the file list.

3. The patch file processing device according to claim 2.

4. The determination unit determines that the target file corresponds to the first package when the first software module is described as an input file in a makefile of the first package.

4. The patch file processing device according to claim 3.

5. the determination unit generates path information indicating a location where the first software module is stored in the information processing device based on the file list; The patch application processing unit applies the patch file candidate to the first software module based on the path information.

4. The patch file processing device according to claim 3.

6. A patch file processing method for applying a patch file to software used by an information processing device, comprising: Identifying a first software module that can be used by the information processing device and a first package to which the first software module belongs, based on a safe list in which software modules that can be used by the information processing device are registered; determining whether a target file to which the candidate patch file is to be applied corresponds to the first package based on a description of the candidate patch file; When the target file corresponds to the first package, the patch file is applied to the first software module. A patch file processing method comprising:

Images