diff options
Diffstat (limited to 'docs/manual/patch-policy.txt')
| -rw-r--r-- | docs/manual/patch-policy.txt | 46 |
1 files changed, 23 insertions, 23 deletions
diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt index 551ea1288..1fdb04ef7 100644 --- a/docs/manual/patch-policy.txt +++ b/docs/manual/patch-policy.txt @@ -10,16 +10,16 @@ necessary to patch the source of the software to get it built within Buildroot. Buildroot offers an infrastructure to automatically handle this during -the builds. It support several ways of applying patch sets: +the builds. It supports several ways of applying patch sets: -Provinding patches -~~~~~~~~~~~~~~~~~~ +Providing patches +~~~~~~~~~~~~~~~~~ -Additionnal tarball -^^^^^^^^^^^^^^^^^^^ +Additional tarball +^^^^^^^^^^^^^^^^^^ -If there needs to apply a patch set available as a tarball and -downloadable, then add the patch tarball to the +<packagename>_PATCH+ +If it is necessary to apply a patch set available as a downloadable +tarball, then add the patch tarball to the +<packagename>_PATCH+ variable. Note that the patch tarballs are downloaded from the same site as the @@ -28,13 +28,13 @@ sources. Within Buildroot ^^^^^^^^^^^^^^^^ -Most of the patches are provided within Buildroot, in the package -directory, because they aim to fix cross-compilation, +libc+ support, -or whatever the reason is. +Most patches are provided within Buildroot, in the package +directory; these typically aim to fix cross-compilation, +libc+ support, +or other such issues. These patch files should have the extension +*.patch+. -A +series+ file, like +quilt+ uses it, may also be added in the +A +series+ file, as used by +quilt+, may also be added in the package directory. In that case, the +series+ file defines the patch application order. @@ -43,7 +43,7 @@ How patches are applied . Run the +<packagename>_PRE_PATCH_HOOKS+ commands if defined; -. Cleanup the build directory from any existing +*.rej+ files; +. Cleanup the build directory, removing any existing +*.rej+ files; . If +<packagename>_PATCH+ is defined, then patches from these tarballs are applied; @@ -65,17 +65,17 @@ If something goes wrong in the steps _3_ or _4_, then the build fails. Format and licensing of the package patches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Patches are released under the same license the software that is +Patches are released under the same license as the software that is modified. -A message explaining what does the patch and why should be add in the -patch's header. +A message explaining what the patch does, and why it is needed, should +be added in the header commentary of the patch. You should add a +signed-off-by+ statement in the header of the each -patch to help keeping track of the changes. +patch to help with keeping track of the changes. -If the software is under versionning, it is recommended to use the SCM -software to generate the patch set. +If the software is under version control, it is recommended to use the +SCM software to generate the patch set. Otherwise, concatenate the header with the output of the +diff -purN source.c.orig source.c+ command. @@ -107,10 +107,10 @@ AC_PROG_MAKE_SET Integrating patches found on the Web ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When integrating a patch whom you are not the author, you have to add -few things in the header of the patch itself. +When integrating a patch of which you are not the author, you have to +add a few things in the header of the patch itself. -Depending on whether the patch has been pick-up from the project +Depending on whether the patch has been obtained from the project repository itself, or from somewhere on the web, add one of the following tags: @@ -124,5 +124,5 @@ or Fetch from: <some url> --------------- -It is also possible to add few words about the changes that may have -been necessary if any. +It is also sensible to add a few words about any changes to the patch +that may have been necessary. |