customize-patches.txt 3.3 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. // -*- mode:doc -*- ;
  2. // vim: set syntax=asciidoc:
  3. === Adding project-specific patches and hashes
  4. [[customize-patches]]
  5. ==== Providing extra patches
  6. It is sometimes useful to apply 'extra' patches to packages - on top of
  7. those provided in Buildroot. This might be used to support custom
  8. features in a project, for example, or when working on a new
  9. architecture.
  10. The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to specify
  11. a space separated list of one or more directories containing package
  12. patches.
  13. For a specific version +<packageversion>+ of a specific package
  14. +<packagename>+, patches are applied from +BR2_GLOBAL_PATCH_DIR+ as
  15. follows:
  16. . For every directory - +<global-patch-dir>+ - that exists in
  17. +BR2_GLOBAL_PATCH_DIR+, a +<package-patch-dir>+ will be determined as
  18. follows:
  19. +
  20. * +<global-patch-dir>/<packagename>/<packageversion>/+ if the
  21. directory exists.
  22. +
  23. * Otherwise, +<global-patch-dir>/<packagename>+ if the directory
  24. exists.
  25. . Patches will then be applied from a +<package-patch-dir>+ as
  26. follows:
  27. +
  28. * If a +series+ file exists in the package directory, then patches are
  29. applied according to the +series+ file;
  30. +
  31. * Otherwise, patch files matching +*.patch+ are applied in
  32. alphabetical order. So, to ensure they are applied in the right
  33. order, it is highly recommended to name the patch files like this:
  34. +<number>-<description>.patch+, where +<number>+ refers to the
  35. 'apply order'.
  36. For information about how patches are applied for a package, see
  37. xref:patch-apply-order[]
  38. The +BR2_GLOBAL_PATCH_DIR+ option is the preferred method for
  39. specifying a custom patch directory for packages. It can be used to
  40. specify a patch directory for any package in buildroot. It should also
  41. be used in place of the custom patch directory options that are
  42. available for packages such as U-Boot and Barebox. By doing this, it
  43. will allow a user to manage their patches from one top-level
  44. directory.
  45. The exception to +BR2_GLOBAL_PATCH_DIR+ being the preferred method for
  46. specifying custom patches is +BR2_LINUX_KERNEL_PATCH+.
  47. +BR2_LINUX_KERNEL_PATCH+ should be used to specify kernel patches that
  48. are available at a URL. *Note:* +BR2_LINUX_KERNEL_PATCH+ specifies kernel
  49. patches that are applied after patches available in +BR2_GLOBAL_PATCH_DIR+,
  50. as it is done from a post-patch hook of the Linux package.
  51. [[customize-hashes]]
  52. ==== Providing extra hashes
  53. Buildroot bundles a xref:adding-packages-hash[list of hashes] against
  54. which it checks the integrity of the downloaded archives, or of those
  55. it generates locally from VCS checkouts. However, it can only do so
  56. for the known versions; for packages where it is possible to specify
  57. a custom version (e.g. a custom version string, a remote tarball URL,
  58. or a VCS repository location and changeset), Buildroot can't carry
  59. hashes for those.
  60. For users concerned with the integrity of such downloads, it is possible
  61. to provide a list of hashes that Buildroot can use to check arbitrary
  62. downloaded files. Those extra hashes are looked up similarly to the
  63. extra patches (above); for each directory in +BR2_GLOBAL_PATCH_DIR+,
  64. the first file to exist is used to check a package download:
  65. * +<global-patch-dir>/<packagename>/<packageversion>/<packagename>.hash+
  66. * +<global-patch-dir>/<packagename>/<packagename>.hash+
  67. The +utils/add-custom-hashes+ script can be used to generate these files.