ivanvoras:pkg_patch

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
ivanvoras:pkg_patch [2010/06/22 16:05] – IvanVorasivanvoras:pkg_patch [2018/03/23 07:22] (current) – wiki markup MarkLinimon
Line 1: Line 1:
 +:idea: Current status: Completed. {{ivanvoras/pkg_patch/pkg_patch.tbz?linkonly|pkg_patch.tbz}}
 +
 +Additional information:
 +
 +  * [[IvanVoras/pkg_patch/FileFormats]]
 +  * [[IvanVoras/pkg_patch/Tutorial]]
 +
 ====== Brainstorming for the pkg_patch project ====== ====== Brainstorming for the pkg_patch project ======
  
-Per %%SoC%% proposal comment, the scope of the project is reduced not to deal with the "ABI stability" aspect of the ports tree.+Per %%SoC%% proposal comment, the scope of the project is reduced not to deal with the "ABI stability" aspect of the ports tree, though it will probably be necessary to make binary patches actually usable.
  
 The project contains these general steps: The project contains these general steps:
Line 10: Line 17:
 ===== pkg_patch ===== ===== pkg_patch =====
  
-The pkg_patch is the central tool for creating and applying binary package patches. It will be made to support different variations on binary package patches, but the first variation will be for them to contain whole files which need patching, for simplicity and avoidance of minuscule differences between binary packages. A future mode will use bsdiff to generate binary patches to the files need patching.+The pkg_patch is the central tool for creating and applying binary package patches. It creates binary patches to packages in which the files to be patched are stored either verbatim or bsdiffed.
  
 In any case, the tool will patch files on the "live" system, in an atomic way (backup+copy+patch files+rename file), along with /var/db/pkg metadata. In any case, the tool will patch files on the "live" system, in an atomic way (backup+copy+patch files+rename file), along with /var/db/pkg metadata.
Line 26: Line 33:
 ===== The update infrastructure ===== ===== The update infrastructure =====
  
-The update infrastructure is to include, in some way, a list of packages and their most recent versions. Depending on how the "ABI stability" aspects of the ports infrastructure is created (if any), the binary package diffs might include only the last versions from a known starting step (e.g. if php5.2.10 was in 8-RELEASE, then the patch repository will contain patches of php5.2.10 to 5.12.11, php5.2.10 to 5.2.12) or all the intermediate versions (e.g. php5.2.10 to php5.2.11, php5.2.11 to php5.2.12). If there are no more inputs from the community, the former will be implemented.+The update infrastructure basically deals with maintaining an index (PKGPATCHINDEX) of created package patches (via the "mass package patch creation" feature), which clients use to determine which packages on their local systems need patching, and to provide these patches to the clients.
  
-In any case, the infrastructure will provide a list of packages to be compared with the local package database and from which the list of packages needing updates can be calculated.+Depending on how the "ABI stability" aspects of the ports infrastructure is created (if any), the binary package diffs might include only the last versions from a known starting step (e.g. if php5.2.10 was in 8.0-RELEASE, then the patch repository will contain patches of php5.2.10 to 5.12.11, php5.2.10 to 5.2.12) or all the intermediate versions (e.g. php5.2.10 to php5.2.11, php5.2.11 to php5.2.12). As the ABI stability question is left dangling, this work will not enforce any such mode.
  
 Brainstorming: Brainstorming:
Line 42: Line 49:
   * pkg_patch: Patch application step: 2 weeks   * pkg_patch: Patch application step: 2 weeks
   * pkg_patch: wrapper or built-in function for generating patches to multiple packages: 1 week   * pkg_patch: wrapper or built-in function for generating patches to multiple packages: 1 week
-  * Update infrastructure: define the format of the list of updates, generate a test set: 1 week+  * Update infrastructure: define the format of the list of updates, generate a test list: 1 week
   * -- midterm --   * -- midterm --
   * pkg_patch: wrapper or built-in function for fetching the list of packages needing the updates, fetching the patches and applying them: 4 weeks   * pkg_patch: wrapper or built-in function for fetching the list of packages needing the updates, fetching the patches and applying them: 4 weeks
Line 50: Line 57:
 ==== RPMs ==== ==== RPMs ====
  
-  * %%PatchRPM%% - contains changed files within the package, part of the regular rpm toolset, used mostly for [[/RedHat|RedHat]]-derived distributions (?), same file format as rpm+  * %%PatchRPM%% - contains changed files within the package, part of the regular rpm toolset, used mostly for %%RedHat%%-derived distributions (?), same file format as rpm
   * %%DeltaRPM%% - contains patches to changed files (binary diffs) within the package, written in python, used in %%SuSE%% (?)   * %%DeltaRPM%% - contains patches to changed files (binary diffs) within the package, written in python, used in %%SuSE%% (?)
  
 ==== DEBs ==== ==== DEBs ====
  
-  * [[/DebDiff|DebDiff]] - can contain both changed files and patches to changed files+  * %%DebDiff%% - can contain both changed files and patches to changed files 
 + 
 +---- 
 + 
 +{{tag>Historical}}
  
  • ivanvoras/pkg_patch.1277222735.txt.gz
  • Last modified: 2010/06/22 16:05
  • by IvanVoras