Skip to content

Commit

Permalink
Add comment (sailfishos-patches#358)
Browse files Browse the repository at this point in the history
* Add comment
  … which answers my …
  #### QUESTION
  Which patch file to backup after 32-/64-bit mangling [in line 183 of `pm_apply`](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L183)?
  #### ADDITIONAL INFORMATION
  I stumbled across this, because usually [the variable `PATCH_PATH="$PATCH_DIR/$PATCH_NAME"` (line 23)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L23) should be used in aforementioned line 183 of the [function `create_backup_patch`](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L175-L186), instead of using `"$PATCH_DIR/$PATCH_NAME"`.
  But when asking myself, if this may be done on purpose (i.e., if this makes a difference), I think it does, if the mangling became active, but had no idea if this was intentional.
  * `PATCH_PATH="$PATCH_DIR/$PATCH_NAME"` is set early (in line 23), so it contains the original Patch name as `PATCH_DIR` and always `PATCH_NAME="unified_diff.patch"`.
  * If the mangling was performed successfully, [`PATCH_PATH="$patch_edited_path"` (line 143)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L143) with [patch_edited_path="$PM_PATCH_BACKUP_DIR"/"$PATCH_EDITED_NAME" (line 130)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L130).  Hence … [see new comment]

  … yes, this was intentional, but I forgot why after a year.  Thus documenting in a comment.
  • Loading branch information
Olf0 authored Jan 13, 2023
1 parent 2bd327f commit 19ddc9c
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions src/tools/pm_apply
Original file line number Diff line number Diff line change
Expand Up @@ -180,6 +180,8 @@ create_backup_patch() {
log

mkdir -p "$PM_PATCH_BACKUP_DIR" > /dev/null 2>&1
# Backup the original patch file, NOT $PATCH_PATH, which might be altered by 32-/64-bit mangling in line 143.
# If mangling was performed successfully, it already wrote its patched $PATCH_EDITED_NAME to $PM_PATCH_BACKUP_DIR in line 134.
cp -f "$PATCH_DIR/$PATCH_NAME" "$PM_PATCH_BACKUP_DIR" > /dev/null 2>&1
log "Created backup: $PM_PATCH_BACKUP_DIR"
log
Expand Down

0 comments on commit 19ddc9c

Please sign in to comment.