rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
// -*- mode:doc -*- ;
|
|
|
|
|
|
|
|
|
|
[[packages-custom]]
|
manual: use one-line titles instead of two-line titles (trivial)
Asciidoc supports two syntaxes for section titles: two-line titles (title
plus underline consisting of a particular symbol), and one-line titles
(title prefixed with a specific number of = signs).
The two-line title underlines are:
Level 0 (top level): ======================
Level 1: ----------------------
Level 2: ~~~~~~~~~~~~~~~~~~~~~~
Level 3: ^^^^^^^^^^^^^^^^^^^^^^
Level 4 (bottom level): ++++++++++++++++++++++
and the one-line title prefixes:
= Document Title (level 0) =
== Section title (level 1) ==
=== Section title (level 2) ===
==== Section title (level 3) ====
===== Section title (level 4) =====
The buildroot manual is currenly using the two-line titles, but this has
multiple disadvantages:
- asciidoc also uses some of the underline symbols for other purposes (like
preformatted code, example blocks, ...), which makes it difficult to do
mass replacements, such as a planned follow-up patch that needs to move
all sections one level down.
- it is difficult to remember which level a given underline symbol (=-~^+)
corresponds to, while counting = signs is easy.
This patch changes all two-level titles to one-level titles in the manual.
The bulk of the change was done with the following Python script, except for
the level 1 titles (-----) as these underlines are also used for literal
code blocks.
This patch only changes the titles, no other changes. In
adding-packages-directory.txt, I did add missing newlines between some
titles and their content.
----------------------------------------------------------------------------
#!/usr/bin/env python
import sys
import mmap
import re
for input in sys.argv[1:]:
f = open(input, 'r+')
f.flush()
s = mmap.mmap(f.fileno(), 0)
# Level 0 (top level): ====================== =
# Level 1: ---------------------- ==
# Level 2: ~~~~~~~~~~~~~~~~~~~~~~ ===
# Level 3: ^^^^^^^^^^^^^^^^^^^^^^ ====
# Level 4 (bottom level): ++++++++++++++++++++++ =====
def replace_title(s, symbol, replacement):
pattern = re.compile(r'(.+\n)\%s{2,}\n' % symbol, re.MULTILINE)
return pattern.sub(r'%s \1' % replacement, s)
new = s
new = replace_title(new, '=', '=')
new = replace_title(new, '+', '=====')
new = replace_title(new, '^', '====')
new = replace_title(new, '~', '===')
#new = replace_title(new, '-', '==')
s.seek(0)
s.write(new)
s.resize(s.tell())
s.close()
f.close()
----------------------------------------------------------------------------
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-02 07:47:30 +02:00
|
|
|
=== Customizing packages
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
|
|
|
|
It is sometimes useful to apply 'extra' patches to packages - over and
|
|
|
|
|
above those provided in Buildroot. This might be used to support custom
|
|
|
|
|
features in a project, for example, or when working on a new architecture.
|
|
|
|
|
|
2013-12-18 11:25:02 +01:00
|
|
|
The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to specify
|
|
|
|
|
a space separated list of one or more directories containing package
|
|
|
|
|
patches. By specifying multiple global patch directories, a user could
|
|
|
|
|
implement a layered approach to patches. This could be useful when a
|
|
|
|
|
user has multiple boards that share a common processor architecture.
|
|
|
|
|
It is often the case that a subset of patches for a package need to be
|
|
|
|
|
shared between the different boards a user has. However, each board
|
|
|
|
|
may require specific patches for the package that build on top of the
|
|
|
|
|
common subset of patches.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2013-12-18 11:25:02 +01:00
|
|
|
For a specific version +<packageversion>+ of a specific package
|
|
|
|
|
+<packagename>+, patches are applied from +BR2_GLOBAL_PATCH_DIR+ as
|
|
|
|
|
follows:
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2013-12-18 11:25:02 +01:00
|
|
|
. For every directory - +<global-patch-dir>+ - that exists in
|
|
|
|
|
+BR2_GLOBAL_PATCH_DIR+, a +<package-patch-dir>+ will be determined as
|
|
|
|
|
follows:
|
|
|
|
|
+
|
|
|
|
|
* +<global-patch-dir>/<packagename>/<packageversion>/+ if the
|
|
|
|
|
directory exists.
|
|
|
|
|
+
|
|
|
|
|
* Otherwise, +<global-patch-dir>/<packagename>+ if the directory
|
|
|
|
|
exists.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2013-12-18 11:25:02 +01:00
|
|
|
. Patches will then be applied from a +<package-patch-dir>+ as
|
|
|
|
|
follows:
|
|
|
|
|
+
|
|
|
|
|
* If a +series+ file exists in the package directory, then patches are
|
|
|
|
|
applied according to the +series+ file;
|
|
|
|
|
+
|
|
|
|
|
* Otherwise, patch files matching +<packagename>-*.patch+
|
|
|
|
|
are applied in alphabetical order.
|
|
|
|
|
So, to ensure they are applied in the right order, it is highly
|
|
|
|
|
recommended to name the patch files like this:
|
|
|
|
|
+<packagename>-<number>-<description>.patch+, where +<number>+
|
|
|
|
|
refers to the 'apply order'.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2013-12-18 11:25:02 +01:00
|
|
|
For information about how patches are applied for a package, see
|
|
|
|
|
xref:patch-apply-order[]
|
|
|
|
|
|
|
|
|
|
The +BR2_GLOBAL_PATCH_DIR+ option is the preferred method for
|
|
|
|
|
specifying a custom patch directory for packages. It can be used to
|
|
|
|
|
specify a patch directory for any package in buildroot. It should also
|
|
|
|
|
be used in place of the custom patch directory options that are
|
|
|
|
|
available for packages such as U-Boot and Barebox. By doing this, it
|
|
|
|
|
will allow a user to manage their patches from one top-level
|
|
|
|
|
directory.
|
|
|
|
|
|
|
|
|
|
The exception to +BR2_GLOBAL_PATCH_DIR+ being the preferred method for
|
|
|
|
|
specifying custom patches is +BR2_LINUX_KERNEL_PATCH+.
|
|
|
|
|
+BR2_LINUX_KERNEL_PATCH+ should be used to specify kernel patches that
|
2014-03-20 23:07:26 +01:00
|
|
|
are available at an URL. *Note:* +BR2_LINUX_KERNEL_PATCH+ specifies kernel
|
|
|
|
|
patches that are applied after patches available in +BR2_GLOBAL_PATCH_DIR+,
|
|
|
|
|
as it is done from a post-patch hook of the Linux package.
|
2013-12-18 11:25:02 +01:00
|
|
|
|
|
|
|
|
An example directory structure for where a user has multiple
|
|
|
|
|
directories specified for +BR2_GLOBAL_PATCH_DIR+ may look like this:
|
|
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
board/
|
|
|
|
|
+-- common-fooarch
|
|
|
|
|
| +-- patches
|
|
|
|
|
| +-- linux
|
|
|
|
|
| | +-- linux-patch1.patch
|
|
|
|
|
| | +-- linux-patch2.patch
|
2014-01-01 12:03:11 +01:00
|
|
|
| +-- uboot
|
2013-12-18 11:25:02 +01:00
|
|
|
| +-- foopkg
|
|
|
|
|
+-- fooarch-board
|
|
|
|
|
+-- patches
|
|
|
|
|
+-- linux
|
|
|
|
|
| +-- linux-patch3.patch
|
2014-01-01 12:03:11 +01:00
|
|
|
+-- uboot
|
2013-12-18 11:25:02 +01:00
|
|
|
+-- foopkg
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
|
|
If the user has the +BR2_GLOBAL_PATCH_DIR+ configuration option set as
|
|
|
|
|
follows:
|
|
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
BR2_GLOBAL_PATCH_DIR="board/common-fooarch board/fooarch-board"
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
|
|
Then the patches would applied as follows for the Linux kernel:
|
|
|
|
|
|
|
|
|
|
. board/common-fooarch/patches/linux/linux-patch1.patch
|
|
|
|
|
. board/common-fooarch/patches/linux/linux-patch2.patch
|
|
|
|
|
. board/fooarch-board/patches/linux/linux-patch3.patch
|
