|author||Alexander Mukhin <firstname.lastname@example.org>||2017-09-14 17:47:42 +0300|
|committer||Arnout Vandecappelle (Essensium/Mind) <email@example.com>||2017-09-24 14:43:37 +0200|
docs: clarify <packagename>_PATCH behaviour
Reiterate once more that <packagename>_PATCH variable can point to an arbitrary URL, not just to a path relative to <packagename>_SITE. While we're at it, also explain that the patch should be added to the .hash file. Signed-off-by: Alexander Mukhin <firstname.lastname@example.org> [Arnout: add sentence about .hash file.] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email@example.com>
Diffstat (limited to 'docs')
1 files changed, 8 insertions, 3 deletions
diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index e1df8b003f..e704a0d3f3 100644
@@ -19,9 +19,14 @@ global patch directory.
If it is necessary to apply a patch that is available for download, then add it
-to the +<packagename>_PATCH+ variable. It is downloaded from the same site
-as the package itself. It can be a single patch, or a tarball containing a
+to the +<packagename>_PATCH+ variable. If an entry contains +://+,
+then Buildroot will assume it is a full URL and download the patch
+from this location. Otherwise, Buildroot will assume that the patch should be
+downloaded from +<packagename>_SITE+. It can be a single patch,
+or a tarball containing a patch series.
+Like for all downloads, a hash should be added to the +<packagename>.hash+
This method is typically used for packages from Debian.