patch-policy.txt 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. [[patch-policy]]
  4. Patching a package
  5. ------------------
  6. While integrating a new package or updating an existing one, it may be
  7. necessary to patch the source of the software to get it cross-built within
  8. Buildroot.
  9. Buildroot offers an infrastructure to automatically handle this during
  10. the builds. It supports three ways of applying patch sets: downloaded patches,
  11. patches supplied within buildroot and patches located in a user-defined
  12. global patch directory.
  13. Providing patches
  14. ~~~~~~~~~~~~~~~~~
  15. Downloaded
  16. ^^^^^^^^^^
  17. If it is necessary to apply a patch that is available for download, then add it
  18. to the +<packagename>_PATCH+ variable. It is downloaded from the same site
  19. as the package itself. It can be a single patch, or a tarball containing a
  20. patch series.
  21. This method is typically used for packages from Debian.
  22. Within Buildroot
  23. ^^^^^^^^^^^^^^^^
  24. Most patches are provided within Buildroot, in the package
  25. directory; these typically aim to fix cross-compilation, libc support,
  26. or other such issues.
  27. These patch files should be named +<packagename>-<number>-<description>.patch+.
  28. A +series+ file, as used by +quilt+, may also be added in the
  29. package directory. In that case, the +series+ file defines the patch
  30. application order.
  31. .Notes
  32. - The patch files coming with Buildroot should not contain any package version
  33. reference in their filename.
  34. - The field +<number>+ in the patch file name refers to the 'apply order'.
  35. Global patch directory
  36. ^^^^^^^^^^^^^^^^^^^^^^
  37. The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
  38. used to specify a space separated list of one or more directories
  39. containing global package patches. See xref:packages-custom[] for
  40. details.
  41. [[patch-apply-order]]
  42. How patches are applied
  43. ~~~~~~~~~~~~~~~~~~~~~~~
  44. . Run the +<packagename>_PRE_PATCH_HOOKS+ commands if defined;
  45. . Cleanup the build directory, removing any existing +*.rej+ files;
  46. . If +<packagename>_PATCH+ is defined, then patches from these
  47. tarballs are applied;
  48. . If there are some +*.patch+ files in the package's Buildroot
  49. directory or in a package subdirectory named +<packageversion>+,
  50. then:
  51. +
  52. * If a +series+ file exists in the package directory, then patches are
  53. applied according to the +series+ file;
  54. +
  55. * Otherwise, patch files matching +<packagename>-*.patch+
  56. are applied in alphabetical order.
  57. So, to ensure they are applied in the right order, it is highly
  58. recommended to name the patch files like this:
  59. +<packagename>-<number>-<description>.patch+, where +<number>+
  60. refers to the 'apply order'.
  61. . If +BR2_GLOBAL_PATCH_DIR+ is defined, the directories will be
  62. enumerated in the order they are specified. The patches are applied
  63. as described in the previous step.
  64. . Run the +<packagename>_POST_PATCH_HOOKS+ commands if defined.
  65. If something goes wrong in the steps _3_ or _4_, then the build fails.
  66. Format and licensing of the package patches
  67. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  68. Patches are released under the same license as the software that is
  69. modified.
  70. A message explaining what the patch does, and why it is needed, should
  71. be added in the header commentary of the patch.
  72. You should add a +Signed-off-by+ statement in the header of the each
  73. patch to help with keeping track of the changes and to certify that the
  74. patch is released under the same license as the software that is modified.
  75. If the software is under version control, it is recommended to use the
  76. upstream SCM software to generate the patch set.
  77. Otherwise, concatenate the header with the output of the
  78. +diff -purN package-version.orig/ package-version/+ command.
  79. At the end, the patch should look like:
  80. ---------------
  81. configure.ac: add C++ support test
  82. Signed-off-by: John Doe <john.doe@noname.org>
  83. --- configure.ac.orig
  84. +++ configure.ac
  85. @@ -40,2 +40,12 @@
  86. AC_PROG_MAKE_SET
  87. +
  88. +AC_CACHE_CHECK([whether the C++ compiler works],
  89. + [rw_cv_prog_cxx_works],
  90. + [AC_LANG_PUSH([C++])
  91. + AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
  92. + [rw_cv_prog_cxx_works=yes],
  93. + [rw_cv_prog_cxx_works=no])
  94. + AC_LANG_POP([C++])])
  95. +
  96. +AM_CONDITIONAL([CXX_WORKS], [test "x$rw_cv_prog_cxx_works" = "xyes"])
  97. ---------------
  98. Integrating patches found on the Web
  99. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  100. When integrating a patch of which you are not the author, you have to
  101. add a few things in the header of the patch itself.
  102. Depending on whether the patch has been obtained from the project
  103. repository itself, or from somewhere on the web, add one of the
  104. following tags:
  105. ---------------
  106. Backported from: <some commit id>
  107. ---------------
  108. or
  109. ---------------
  110. Fetch from: <some url>
  111. ---------------
  112. It is also sensible to add a few words about any changes to the patch
  113. that may have been necessary.