The following paper was originally presented at the Ninth System Administration Conference (LISA ’95) Monterey, California, September 18-22, 1995
Patch Control Mechanism for Large Scale Software
Atsushi Futakata Central Research Institute of Electric Power Industry (CRIEPI)
For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org Patch Control Mechanism for Large Scale Software Atsushi Futakata – Central Research Institute of Electric Power Industry (CRIEPI)
ABSTRACT Applying patches to large scale software is often difficult because unofficial patches and user modifications conflict with any ‘‘official’’ patches. Version control systems such as RCS[1], CVS[2], and configuration management[3,4,5] are useful solutions for this problem when the baseline of the software is fixed. However, an official patch that is developed externally changes the baseline and any local changes based on this become obsolete. Thus we must re-apply various unofficial patches and modifications, identify the causes of conflict, change or remove patches, and repeat the patch and unpatch operations. This paper presents a mechanism for (1) managing versions of a software package based on patches, (2) automating the application of unofficial patches and modifications by the user, and (3) rebuilding the package using file versions instead of timestamps. Using this mechanism, it becomes easy to apply patches and re-build software.
Introduction Configuration management systems such as Aegis[7], CMS/MMS[8] are useful for version con- We have spent a lot of time installing and trol and building software for multi-user develop- patching large scale software packages such as the ment. They target the continuous development of the X11 Window System, TeX, etc. Installation of new software and manage products based on a current software involves checking storage space, reading baseline, that is a reference version of software on documentation and setting various configuration files which each member of developing team fixes bugs correctly. This can be a non-trivial task even if the and develops new functions. After each task is com- platform is officially supported. If the platform is plete, all modifications are integrated and the not supported, installation becomes more compli- modified source code becomes a new baseline for cated because changes to the source code may be succeeding development. This baseline approach is required and tools such as Configure are not applica- useful for inhouse development teams. ble. Thus software porting systems represented by the FreeBSD ports system[6] appear and become to However, an official patch is delivered outside support the installation task. of a user’s control and it only changes the baseline. All modifications based on the previous version of Applying patches poses another difficult prob- the software then become obsolete. Thus if the user lem: If only official patches are applied to an wants to apply a new official patch, all other patches officially supported platform, the task is usually easy and modifications must be rearranged and re-applied because the patches are well managed and cause no after the official one is applied. conflict. However an unsupported platform requires source code changes which often conflict with an In future, self-adaptive software agents or official patch. Furthermore, the user may require automatic programming from very high level many useful, unofficial patches. These may be specifications may solve the problem but, for the patches for emergency security, localization (e.g., present, we have no silver bullet. Thus, in order to japanization), machine/OS-dependencies or various solve the above problem and support patch applica- extensions, such as Tcl/Tk has. Those patches may tion, this paper proposes a patch control mechanism also conflict with official ones. The reason for the which has the following features: conflict is a lack of version management facilities version management of the whole package, for distributed development. This conflict usually including individual files and patches, necessitates the following operation: management and control of patch application Remove all unofficial patches and apply the order, official one, assistance with patch/unpatch operations and Re-apply the unofficial patches and user patch modification, modifications. If reject files are generated, the software rebuilding according to an individual unofficial patch must be fixed or removed, file version rather than a timestamp. Rebuild the software. This can take a long time because the above operations may cause unnecessary changes to timestamps.
1995 LISA IX – September 17-22, 1995 – Monterey, CA 213 Patch Control Mechanism for Large Scale Software Futakata
Classification of patches location of the patches and the versions of individual files. The version tree records the application order Unofficial patches may be generated by dif- for unofficial patches and modifications at each ferent people based on different baselines. Unified patchlevel. When a new patch arrives, the user adds management of these patches can be difficult and the patch to the VDB using the VM. If the user confusing. In this paper, we classify patches into the wants to apply this, and the result is successful, the following three types and treat each differently. VM registers the sequence of patches actually official patch applied, to the version tree. A patch that is authorized by and distributed from the software developer/maintainer. The The PM (Patch Manager) controls the latest official patch number is the official patch/unpatch operations and the building of the software version and we call it the patchlevel. software according to the version tree. In this sys- unofficial patch tem, all operations, including editing a patch file, A patch/extension that is widely distributed applying a patch, and building a package, are per- but is not an official patch. An unofficial formed via the PM, and the result of the operation is patch may be applied in various directories reflected in the VDB and the version tree. with various patch (1) options. When a user applies a new official patch, the modification PM tries to apply unofficial patches which were A change made by the local user, which applied to the last version of software. If one of the includes editing files, fixing bugs, changing patches is rejected, the PM notifies the user. The configuration files, etc. user may then remove or edit this patch and continue the job. After the job finished, the PM returns the System Overview result of the patch application and the VM revises This section presents an overview of the system the VDB and the version tree. which is an implementation of the patch control The BM (Building Manager) is an extended mechanism. This includes; (1) management of the make command, invoked from the PM to build a tar- three types of patch, (2) control of patch application, get according to the version of file instead of its and (3) rebuilding of the software. The components timestamp. Because a new official patch forces VM (Version Manager), PM (Patch Manager), and patch/unpatch operations of unofficial patches and BM (Build Manager) implement the three functions modifications, the timestamp of a file may change respectively. Figure 1 shows the components and even if the contents is not altered. The VM registers the relation among them. the version of the newly generated target with the VDB and the version tree. USER This system manages several packages at once by referring to the pcm file. An entry of the pcm file has the following form: application_name:top_directory:patch_option PM Application_name is an identifier to be used for selecting a package. Top_directory is the directory get info. invoke where official patches are applied. Patch_option & register species an option to the patch (1) command. For example, the entry for X11R5 (X11 Window System, Version 11, Release 5) becomes1: VM apply BM patch X11R5:/X11R5:-p -s This means that the following command is needed to build manage manage apply the patch. software software % cd /X11R5 ...... % patch -p -s 214 1995 LISA IX – September 17-22, 1995 – Monterey, CA Futakata Patch Control Mechanism for Large Scale Software patches independent of the baseline specified by an apply them. Each entry of this file has the following official patch. Thus each unofficial patch and form; modification has a separate version to avoid conflicts id:location:place:option which may occur with any new official patch. The versions of these patches are managed using RCS. Id is the unofficial patch identifier which is used in the version tree. Location is the location of the The VM manages the patch information, unofficial patch. Place is the directory in which the including the location of patches, versions of patches patch is applied, and option is the patch (1) options. themselves and the history of patch application. The In general, there is no standard method for applying VM performs the following functions: unofficial patches, and this is a reason for the place generates the specified version of a software and option fields. Figure 3 shows a part of .unof- package or a file by applying patches automat- ficial for X11R5. ically, registers/deletes/updates a patch, @1:/X11R5/fixes/Xaw-p1:/X11R5:-p0 creates/updates a modification from the differ- @2:/X11R5/fixes/Xsi-p1:/X11R5:-p0 ences between a modified file and its original, @3:/X11R5/fixes/Xwchar-p1:/X11R5:-p0 maintains versions of files, which are deter- @4:/X11R5/fixes/Xaw-p2:/X11R5:-p0 mined by the patches which actually cause change. Figure 3: A sample of .unofficial file for X11R5 Information managed by the VM is recorded in Versions of the patches are managed by RCS the VDB and the version tree. The VDB consists of and the RCS file for each patch is located in direc- the locations and the versions of patches and the ver- tory of location/RCS. A user can edit the patched sions of the individual files. The version tree files themselves instead of the patch because it is describes the order of patch application required to almost impossible to edit the patch directly. Changes make the specified version of software, and which to the files are reflected in the patch by the follow- version of each patch should be applied. ing process: The version of the software package itself is choose the version of the software and the tar- represented by a path of the version tree. For exam- get patch to be edited. For example, we ple, #3:@1.2,@2.1,@3.2:$1.2 means that the assume that the patch is @3.1 which changes version is generated by application of an official two files, foo.c and bar.c, and the version patch #3, unofficial patches @1.2, @2.1, and is #3:@1.2,@2.1,@3.1, @3.2, and a modification $1.2 in order. The fol- apply the sequence of patches which should lowing section describes the contents of the VDB be applied in this version before applying the and the version tree. target patch. After that, make a copy of the patched file and apply the target patch. In #26 this example, first, the VM applies @1.2 and #1:/X11R5/fixes/fix-01 @2.1 to the software whose patchlevel is #3. #2:/X11R5/fixes/fix-02 Next, the VM makes copies of foo.c and #3:/X11R5/fixes/fix-03 bar.c with an extension .prev. Then, the #4:/X11R5/fixes/fix-04 VM applies @3.1 to the software, Figure 2: A part of .official file for X11R5 after editing the patched files, make a new patch by running diff (1) against the files of Version Database which the VM made copies in the last step. The VDB consists of the four files. In this example, the two diff files between foo.c/bar.c and .official foo.c.prev/bar.c.prev are con- .official contains the current patchlevel catenated to a new patch, whose path name is and the locations of official patches. The first line is the same as @3.1. the current patchlevel of the software. The follow- check in the new patch using ci (1) . In this ing lines contain a patch identifier (which is used in example, the VM runs the following com- the version tree), and a corresponding patch location. mand: Figure 2 is a sample of a part of a .official file. #26 in line 1 means that the current patchlevel is % ci -r2.1 location of @3 26. The lines 2-5 specify the location of each official in which 2 of 2.1 is the new version number patch. For example, line 2 means that the location of for the patch @3. the official patch #1 is /X11R5/fixes/fix-01. The VM normally uses only the release number .unofficial of RCS. Thus a patch with version N has a revision .unofficial contains the locations of N.1 in the RCS file. For example, when applying unofficial patches and the information required to the version 3 of the patch @1 in the Figure 5, the following commands are needed: 1995 LISA IX – September 17-22, 1995 – Monterey, CA 215 Patch Control Mechanism for Large Scale Software Futakata % co -l -r3.1 /X11R5/fixes/Xaw-p1 Version tree % cd /X11R5 The version tree manages the software version % patch -p0 216 1995 LISA IX – September 17-22, 1995 – Monterey, CA Futakata Patch Control Mechanism for Large Scale Software a user can specify the ver in the form given in which the patch was applied and the PM the version tree, or as the entry number in the applies a next patch. The user can edit it version tree which the user can obtain by before replying to the PM. In this operation, sending the command scan -v. This causes a the user can refer to the whole patch by send- change to an unofficial patch or a ing a command to the PM. When the all modification. replies are gathered, the PM replaces the parts add [-o |-u] patch_info of the patch and reflects the change in the register an official/unofficial patch with the RCS file using ci (1). After that, the VM tries patch_info. The patch_info has the same to apply the next patch. form as in .official or .unofficial 4. create a new entry in the version tree. If user without the identifier. The identifier is added wants to rebuild the software, the PM invokes by the VM. the BM. scan [-v |-o |-u |-m] 5. unpatch all the unofficial patches and the show the contents of .vtree, .offi- modifications. cial, .unofficial,or.modifica- When applying a new unofficial patch, the user tion. should specify the version tree entry which includes show id (ver) the new patch. This new version tree entry is show the contents of patch whose identifier is registered if the application process has terminated id in the software version ver. If the ver is successfully. The other operations are similar to the omitted, show shows the patch that has been above case for official patches. applied in the current version of software, or If reject files are generated, the PM sends e- the latest version of the patch if the current mail to the user per reject file. Figure 6 is a sample version of software does not include this. of the e-mail, which notifies that application of apply id (ver) unofficial patch $1.1 has been failed in sun.cf2. apply a patch whose identifier is id. If the The body of e-mail is the contents of sun.cf and patch is an official patch, a user does not need the rejected file is embedded in it. to specify the ver. If the patch is an unofficial patch or a modification, the user must To: futakata specifies the ver as the full path form. Pro- Subject: REJECTION $1.1: sun.cf cessing of the apply function is described From: PCM 1995 LISA IX – September 17-22, 1995 – Monterey, CA 217 Patch Control Mechanism for Large Scale Software Futakata To: [email protected] #0::$1.1,$2.1,$3.1,$4.1 Subject: RE: REJECTION $1.1: sun.cf #1::$1.1,$2.1,$3.1.$4.1 From: [email protected] #2::$1.1,$2.1,$3.2.$4.1 #3:@[email protected],@3.1:$1.2,$2.1,$3.3,$4.1 replace #4:@1.1,@2.1,@3.1:$1.2,$2.1,$3.3,$4.1 218 1995 LISA IX – September 17-22, 1995 – Monterey, CA Futakata Patch Control Mechanism for Large Scale Software of Software Engineering, Vol. SE-10, No. 1, 1984. [4] Whitgift, D.: Methods and Tools for Software Configuration Management, John Wiley and Sons, 1991. [5] Eaton, D.: ‘‘comp.software.config-mgmt FAQ version 1.12’’, posted to the comp. software.config-mgmt, 1995. [6] Palmer, G. and Hubbard, J. K.: ‘‘The FreeBSD Ports FAQ file version 1.1’’, included in the FreeBSD rel.2.0.5 package, 1995. [7] Miller, P.: ‘‘Aegis: A project Change Supervi- sor User Guide’’, included in the aegis ver.2.1 package, 1993. [8] DEC: CASE Environment of DEC: COHESION - COHESION handbook rev.1, DEC, 1991. 1995 LISA IX – September 17-22, 1995 – Monterey, CA 219 220 1995 LISA IX – September 17-22, 1995 – Monterey, CA