|
|
2a1cf3d |
# Fedora GDB local patches policy
|
|
|
f637971 |
|
|
|
f637971 |
In order to make things easier for the Fedora GDB maintainer, we
|
|
|
f637971 |
choose to auto-generate the local patches by making use of an upstream
|
|
|
f637971 |
git repository. Below you can find a few instructions on how to work
|
|
|
f637971 |
using this method.
|
|
|
f637971 |
|
|
|
f637971 |
You need to run the following commands from the directory that
|
|
|
f637971 |
contains the "gdb.spec" file.
|
|
|
f637971 |
|
|
|
2a1cf3d |
## Importing the GDB patches into a git repository
|
|
|
f637971 |
|
|
|
2a1cf3d |
1) The local patches (`*.patch`) need to be imported into an upstream
|
|
|
f637971 |
git repository. For example, let's assume you cloned the repository
|
|
|
f637971 |
by doing:
|
|
|
f637971 |
|
|
|
2a1cf3d |
`$ git clone git://sourceware.org/git/binutils-gdb.git`
|
|
|
f637971 |
|
|
|
2a1cf3d |
> TIP: if you already have the repository cloned somewhere in your
|
|
|
2a1cf3d |
> system, you can pass a "--reference <dir>" to the "git clone"
|
|
|
2a1cf3d |
> command and it will use your local repository as much as possible
|
|
|
2a1cf3d |
> to make the clone, speeding up things.
|
|
|
f637971 |
|
|
|
f637971 |
2) After cloning the upstream repository, you can import your patches
|
|
|
f637971 |
by using the script "generate-git-repo-from-patches.sh":
|
|
|
f637971 |
|
|
|
2a1cf3d |
`$ sh generate-git-repo-from-patches.sh <REPOSITORY_DIR>`
|
|
|
f637971 |
|
|
|
f637971 |
The script will basically cd into the repository, checkout the
|
|
|
2a1cf3d |
revision specified in the file `_git_upstream_commit`, iterate through
|
|
|
2a1cf3d |
the file `_patch_order` and "git-am" every patch *in that order*.
|
|
|
f637971 |
This operation should complete without errors; if you find a problem
|
|
|
2a1cf3d |
with `git-am`, it probably means that the revision specified in the
|
|
|
2a1cf3d |
file `_git_upstream_commit` is wrong.
|
|
|
f637971 |
|
|
|
2a1cf3d |
## Rebasing the patches against a newer version/release
|
|
|
f637971 |
|
|
|
f637971 |
1) First, cd into the upstream repository. All you have to do is
|
|
|
f637971 |
choose the revision against which you plan to rebase the patches, and
|
|
|
2a1cf3d |
`git rebase <REVISION>`. git will do the rest, and you will be able
|
|
|
f637971 |
to perform conflict resolution by git's algorithm, which is smarter.
|
|
|
f637971 |
|
|
|
2a1cf3d |
## Creating new patches
|
|
|
f637971 |
|
|
|
f637971 |
1) Create the new patch on top of the the others, as usual. Note that
|
|
|
2a1cf3d |
you can use `git rebase` whenever you want to reorder patch order, or
|
|
|
f637971 |
even to delete a patch.
|
|
|
f637971 |
|
|
|
f637971 |
2) When writing the commit log, you must obey a few rules. The
|
|
|
fd7e5d7 |
subject line *must* be the filename of the patch. This line will be
|
|
|
fd7e5d7 |
used when exporting the patches from the git repository, and
|
|
|
fd7e5d7 |
(obviously) it gives the filename that should be used for this
|
|
|
fd7e5d7 |
specific patch.
|
|
|
f637971 |
|
|
|
f637971 |
3) You can also add comments that will go into the auto-generated
|
|
|
2a1cf3d |
`Patch:` file (see below). To do that, use the special marker `;;` at
|
|
|
f637971 |
the beginning of the line. This way, a commit log that says:
|
|
|
f637971 |
|
|
|
2a1cf3d |
~~~~~~~~~~~
|
|
|
fd7e5d7 |
test-patch.patch
|
|
|
f637971 |
|
|
|
f637971 |
;; This is a test patch
|
|
|
f637971 |
;; Second line
|
|
|
2a1cf3d |
~~~~~~~~~~~
|
|
|
f637971 |
|
|
|
2a1cf3d |
Will generate the following entry in the auto-generated `Patch:` file:
|
|
|
f637971 |
|
|
|
2a1cf3d |
~~~~~~~~~~~
|
|
|
f637971 |
# This is a test patch
|
|
|
f637971 |
# Second line
|
|
|
f637971 |
PatchXYZ: test-patch.patch
|
|
|
2a1cf3d |
~~~~~~~~~~~
|
|
|
f637971 |
|
|
|
2a1cf3d |
## Exporting the GDB patches from the git repository
|
|
|
f637971 |
|
|
|
f637971 |
1) When you're done working with the patches, go back to the directory
|
|
|
2a1cf3d |
that contains the `gdb.spec` file, and from there you run:
|
|
|
f637971 |
|
|
|
2a1cf3d |
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>`
|
|
|
f637971 |
|
|
|
2a1cf3d |
This will regenerate all of the `*.patch` files (excluding the ones that
|
|
|
f637971 |
were also excluded from the git repository), and also regenerate a few
|
|
|
f637971 |
control files. These control files are:
|
|
|
f637971 |
|
|
|
2a1cf3d |
- `_gdb.spec.Patch.include`: This file contains the `Patch:` directives.
|
|
|
f637971 |
|
|
|
2a1cf3d |
- `_gdb.spec.patch.include`: This file contains the `%patch` directives.
|
|
|
f637971 |
|
|
|
2a1cf3d |
- `_patch_order`: This file contains the patches, in the exact order
|
|
|
f637971 |
that they must be applied. It is used when importing the patches
|
|
|
f637971 |
into the git repository.
|
|
|
f637971 |
|
|
|
2a1cf3d |
- `_git_upstream_commit`: This file contains the last upstream commit
|
|
|
f637971 |
against which the patches were rebased. It is used when importing
|
|
|
f637971 |
the patches into the git repository.
|
|
|
82f299d |
|
|
|
82f299d |
NOTE: If you did a rebase against a newer upstream version, you need
|
|
|
82f299d |
to specify the commit/tag/branch against which you rebased:
|
|
|
82f299d |
|
|
|
2a1cf3d |
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>`
|
|
|
82f299d |
|
|
|
2a1cf3d |
For example, if you rebased against `gdb-8.1-release`:
|
|
|
82f299d |
|
|
|
2a1cf3d |
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release`
|