[Buildroot] [PATCH v3 1/2] Support for multiple BR2_GLOBAL_PATCH_DIR

[Buildroot] [PATCH v3 1/2] Support for multiple BR2_GLOBAL_PATCH_DIR

[Ryan Barnett]

Adding support for specifying multiple directories in
BR2_GLOBAL_PATCH_DIR. This will allow for a layered approach for the
patching of a package.

Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>

---
Changes v2 -> v3:
  - changed the generation of patch directories to use 'addsuffix'
    instead of a foreach loop. (suggested by Arnout)

Changes v1 -> v2:
  - change wording in Config.in help (suggested by Thomas D)
---
 Config.in              |   20 ++++++++++++--------
 package/pkg-generic.mk |    5 ++++-
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Config.in b/Config.in
index 2b401cb..d55e57c 100644
--- a/Config.in
+++ b/Config.in
@@ -461,18 +461,22 @@ config BR2_PACKAGE_OVERRIDE_FILE
 	  Buildroot documentation for more details on this feature.
 
 config BR2_GLOBAL_PATCH_DIR
-	string "global patch directory"
+	string "global patch directories"
 	help
-	  You may specify a directory containing global package patches.
-	  For a specific version <packageversion> of a specific package
-	  <packagename>, patches are applied as follows.
+	  You may specify a space separated list of one or more directories
+	  containing global package patches. For a specific version
+	  <packageversion> of a specific package <packagename>, patches are
+	  applied as follows:
 
-	  First, the default Buildroot patch set for the package is applied.
+	  First, the default Buildroot patch set for the package is applied
+	  from the package's directory in Buildroot.
 
-	  If the directory $(BR2_GLOBAL_PATCH_DIR)/<packagename>/<packageversion>
-	  exists, then all *.patch files in the directory will be applied.
+	  Then for every directory - <global-patch-dir> - that exists in
+	  BR2_GLOBAL_PATCH_DIR, if the directory
+	  <global-patch-dir>/<packagename>/<packageversion>/ exists, then all
+	  *.patch files in this directory will be applied.
 
-	  Otherwise, if the directory $(BR2_GLOBAL_PATCH_DIR)/<packagename> exists,
+	  Otherwise, if the directory <global-patch-dir>/<packagename> exists,
 	  then all *.patch files in the directory will be applied.
 
 endmenu
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 1fce71b..6773f05 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -134,8 +134,11 @@ endif
 # The RAWNAME variable is the lowercased package name, which allows to
 # find the package directory (typically package/<pkgname>) and the
 # prefix of the patches
+#
+# For BR2_GLOBAL_PATCH_DIR, only generate if it is defined
 $(BUILD_DIR)/%/.stamp_patched: NAMEVER = $(RAWNAME)-$($(PKG)_VERSION)
-$(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME)
+$(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS =  $($(PKG)_DIR_PREFIX)/$(RAWNAME)
+$(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS += $(addsuffix /$(RAWNAME),$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))
 $(BUILD_DIR)/%/.stamp_patched:
 	@$(call step_start,patch)
 	@$(call MESSAGE,"Patching")
-- 
1.7.9.5

[Buildroot] [PATCH v3 2/2] manual: update for multiple global patch dirs

[Ryan Barnett]

Updating the documentation to reflect that multiple directories can
now be specified for BR2_GLOBAL_PATCH_DIR. Along with giving an
example use case of how to use multiple global patch directories.

Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>

---
Changes v2 -> v3:
  - None

Changes v1 -> v2:
  - Fixed minor spelling mistakes and wording (suggested by Thomas D)
---
 docs/manual/customize-packages.txt |   70 +++++++++++++++++++++++++++++++-----
 docs/manual/patch-policy.txt       |   13 ++++---
 2 files changed, 70 insertions(+), 13 deletions(-)

diff --git a/docs/manual/customize-packages.txt b/docs/manual/customize-packages.txt
index 1820c54..8955756 100644
--- a/docs/manual/customize-packages.txt
+++ b/docs/manual/customize-packages.txt
@@ -8,16 +8,68 @@ 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.
 
-The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
-used to specify a directory containing global package patches.
+The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to specify
+a space separated list of one or more directories containing global
+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.
 
-For a specific version <packageversion> of a specific package <packagename>,
-patches are applied as follows.
+For a specific version +<packageversion>+ of a specific package
++<packagename>+, patches are applied as follows:
 
-First, the default Buildroot patch set for the package is applied.
+. First, the default Buildroot patch set for the package is applied.
 
-If the directory +$(BR2_GLOBAL_PATCH_DIR)/<packagename>/<packageversion>+
-exists, then all +*.patch+ files in the directory will be applied.
+. Then for every directory - +<global-patch-dir>+ - that exists in
+  +BR2_GLOBAL_PATCH_DIR+, the following will be done:
++
+* If the directory
+  +<global-patch-dir>/<packagename>/<packageversion>/+ exists, then
+  all *.patch files in this directory will be applied.
++
+* Otherwise, if the directory +<global-patch-dir>/<packagename>+ exists,
+  then all *.patch files in the directory will be applied.
 
-Otherwise, if the directory +$(BR2_GLOBAL_PATCH_DIR)/<packagename>+
-exists, then all +*.patch+ files in the directory will be applied.
+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 for Linux,
+U-Boot, and other packages that already haved custom patch directory
+options available to them. By doing this, it will allow a user to
+manage their patches from one top-level directory.
+
+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
+|       +-- u-boot
+|       +-- foopkg
++-- fooarch-board
+    +-- patches
+        +-- linux
+        |   +-- linux-patch3.patch
+        +-- u-boot
+        +-- 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-patch1.patch
diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index d9bc8ca..26586ad 100644
--- a/docs/manual/patch-policy.txt
+++ b/docs/manual/patch-policy.txt
@@ -50,8 +50,9 @@ Global patch directory
 ^^^^^^^^^^^^^^^^^^^^^^
 
 The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
-used to specify a directory containing global package patches. See
-xref:packages-custom[] for details.
+used to specify a space separated list of one or more directories
+containing global package patches. See xref:packages-custom[] for
+details.
 
 
 How patches are applied
@@ -72,11 +73,15 @@ How patches are applied
 +
 * Otherwise, patch files matching +<packagename>-*.patch+
   are applied in alphabetical order.
-  So, to ensure they are applied in the right order, it is hightly
-  recommended to named the patch files like this:
+  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'.
 
+. If +BR2_GLOABL_PATCH_DIR+ is defined, the directories will be
+  enumerated in the order they are specified for patches. The patches
+  are applied as described in the previous step.
+
 . Run the +<packagename>_POST_PATCH_HOOKS+ commands if defined.
 
 If something goes wrong in the steps _3_ or _4_, then the build fails.
-- 
1.7.9.5

[Buildroot] [PATCH v3 2/2] manual: update for multiple global patch dirs

[Arnout Vandecappelle]

On 13/12/13 11:09, Ryan Barnett wrote:
> Updating the documentation to reflect that multiple directories can
> now be specified for BR2_GLOBAL_PATCH_DIR. Along with giving an
> example use case of how to use multiple global patch directories.
>
> Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>
>
> ---
> Changes v2 -> v3:
>    - None
>
> Changes v1 -> v2:
>    - Fixed minor spelling mistakes and wording (suggested by Thomas D)
> ---
>   docs/manual/customize-packages.txt |   70 +++++++++++++++++++++++++++++++-----
>   docs/manual/patch-policy.txt       |   13 ++++---
>   2 files changed, 70 insertions(+), 13 deletions(-)
>
> diff --git a/docs/manual/customize-packages.txt b/docs/manual/customize-packages.txt
> index 1820c54..8955756 100644
> --- a/docs/manual/customize-packages.txt
> +++ b/docs/manual/customize-packages.txt
> @@ -8,16 +8,68 @@ 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.
>
> -The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
> -used to specify a directory containing global package patches.
> +The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to specify
> +a space separated list of one or more directories containing global
> +package patches. By specifying multiple global patch directories, a

  I think "global package patches" sounds strange. It's the directory 
that is global, not the patches or the packages. So I'd just sai "package 
patches".

> +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.
>
> -For a specific version <packageversion> of a specific package <packagename>,
> -patches are applied as follows.
> +For a specific version +<packageversion>+ of a specific package
> ++<packagename>+, patches are applied as follows:
>
> -First, the default Buildroot patch set for the package is applied.
> +. First, the default Buildroot patch set for the package is applied.
>
> -If the directory +$(BR2_GLOBAL_PATCH_DIR)/<packagename>/<packageversion>+
> -exists, then all +*.patch+ files in the directory will be applied.
> +. Then for every directory - +<global-patch-dir>+ - that exists in
> +  +BR2_GLOBAL_PATCH_DIR+, the following will be done:
> ++
> +* If the directory
> +  +<global-patch-dir>/<packagename>/<packageversion>/+ exists, then
> +  all *.patch files in this directory will be applied.
> ++
> +* Otherwise, if the directory +<global-patch-dir>/<packagename>+ exists,
> +  then all *.patch files in the directory will be applied.

  I would repeat here the explanation about the order in which patches 
are applied, and the recommendation to number them.

The patches in each directory 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'.


>
> -Otherwise, if the directory +$(BR2_GLOBAL_PATCH_DIR)/<packagename>+
> -exists, then all +*.patch+ files in the directory will be applied.
> +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 for Linux,
> +U-Boot, and other packages that already haved custom patch directory
> +options available to them. By doing this, it will allow a user to
> +manage their patches from one top-level directory.

  Actually, BR2_LINUX_KERNEL_PATCH also supports downloading the patch, 
which is not possible with BR2_GLOBAL_PATCH_DIR. As to the others, I 
think these options should just be removed (not deprecated, but really 
removed, with a clear explanation in Config.in.legacy). And in that case 
this paragraph becomes redundant.

> +
> +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
> +|       +-- u-boot
> +|       +-- foopkg
> ++-- fooarch-board
> +    +-- patches
> +        +-- linux
> +        |   +-- linux-patch3.patch
> +        +-- u-boot
> +        +-- 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-patch1.patch

  It's actually patch3 in the example above...

> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index d9bc8ca..26586ad 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -50,8 +50,9 @@ Global patch directory
>   ^^^^^^^^^^^^^^^^^^^^^^
>
>   The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
> -used to specify a directory containing global package patches. See
> -xref:packages-custom[] for details.
> +used to specify a space separated list of one or more directories
> +containing global package patches. See xref:packages-custom[] for
> +details.
>
>
>   How patches are applied
> @@ -72,11 +73,15 @@ How patches are applied
>   +
>   * Otherwise, patch files matching +<packagename>-*.patch+
>     are applied in alphabetical order.
> -  So, to ensure they are applied in the right order, it is hightly
> -  recommended to named the patch files like this:
> +  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'.
>
> +. If +BR2_GLOABL_PATCH_DIR+ is defined, the directories will be
> +  enumerated in the order they are specified for patches. The patches

  I think the "for patches" here is meaningless.


  Regards,
  Arnout

> +  are applied as described in the previous step.
> +
>   . Run the +<packagename>_POST_PATCH_HOOKS+ commands if defined.
>
>   If something goes wrong in the steps _3_ or _4_, then the build fails.
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v3 2/2] manual: update for multiple global patch dirs

[rjbarnet at rockwellcollins.com]

Arnout,

Arnout Vandecappelle <arnout@mind.be> wrote on 12/13/2013 11:19:54 AM:
 
> On 13/12/13 11:09, Ryan Barnett wrote:
[...]

> > diff --git a/docs/manual/customize-packages.txt 
b/docs/manual/customize-packages.txt
> > index 1820c54..8955756 100644
> > --- a/docs/manual/customize-packages.txt
> > +++ b/docs/manual/customize-packages.txt
> > @@ -8,16 +8,68 @@ 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.
> >
> > -The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
> > -used to specify a directory containing global package patches.
> > +The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to 
specify
> > +a space separated list of one or more directories containing global
> > +package patches. By specifying multiple global patch directories, a
> 
>   I think "global package patches" sounds strange. It's the directory 
> that is global, not the patches or the packages. So I'd just sai 
"package 
> patches".

Agree.

> > +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.
> >
> > -For a specific version <packageversion> of a specific package 
<packagename>,
> > -patches are applied as follows.
> > +For a specific version +<packageversion>+ of a specific package
> > ++<packagename>+, patches are applied as follows:
> >
> > -First, the default Buildroot patch set for the package is applied.
> > +. First, the default Buildroot patch set for the package is applied.
> >
> > -If the directory 
+$(BR2_GLOBAL_PATCH_DIR)/<packagename>/<packageversion>+
> > -exists, then all +*.patch+ files in the directory will be applied.
> > +. Then for every directory - +<global-patch-dir>+ - that exists in
> > +  +BR2_GLOBAL_PATCH_DIR+, the following will be done:
> > ++
> > +* If the directory
> > +  +<global-patch-dir>/<packagename>/<packageversion>/+ exists, then
> > +  all *.patch files in this directory will be applied.
> > ++
> > +* Otherwise, if the directory +<global-patch-dir>/<packagename>+ 
exists,
> > +  then all *.patch files in the directory will be applied.
> 
>   I would repeat here the explanation about the order in which patches 
> are applied, and the recommendation to number them.
> 
> The patches in each directory 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'.

Agree.

> >
> > -Otherwise, if the directory +$(BR2_GLOBAL_PATCH_DIR)/<packagename>+
> > -exists, then all +*.patch+ files in the directory will be applied.
> > +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 for Linux,
> > +U-Boot, and other packages that already haved custom patch directory
> > +options available to them. By doing this, it will allow a user to
> > +manage their patches from one top-level directory.
> 
>   Actually, BR2_LINUX_KERNEL_PATCH also supports downloading the patch, 
> which is not possible with BR2_GLOBAL_PATCH_DIR. As to the others, I 
> think these options should just be removed (not deprecated, but really 
> removed, with a clear explanation in Config.in.legacy). And in that case 

> this paragraph becomes redundant.

I will make note of the BR2_LINUX_KERNEL_PATCH supporting the downloading 
of the patch and that is the only way that it should be used. However, I 
would rather submit a separate patch series to deprecate the other 
options. Is this OK with you?

> > +
> > +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
> > +|       +-- u-boot
> > +|       +-- foopkg
> > ++-- fooarch-board
> > +    +-- patches
> > +        +-- linux
> > +        |   +-- linux-patch3.patch
> > +        +-- u-boot
> > +        +-- 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-patch1.patch
> 
>   It's actually patch3 in the example above...

I'll fix that.

> > diff --git a/docs/manual/patch-policy.txt 
b/docs/manual/patch-policy.txt
> > index d9bc8ca..26586ad 100644
> > --- a/docs/manual/patch-policy.txt
> > +++ b/docs/manual/patch-policy.txt
> > @@ -50,8 +50,9 @@ Global patch directory
> >   ^^^^^^^^^^^^^^^^^^^^^^
> >
> >   The +BR2_GLOBAL_PATCH_DIR+ configuration file option can be
> > -used to specify a directory containing global package patches. See
> > -xref:packages-custom[] for details.
> > +used to specify a space separated list of one or more directories
> > +containing global package patches. See xref:packages-custom[] for
> > +details.
> >
> >
> >   How patches are applied
> > @@ -72,11 +73,15 @@ How patches are applied
> >   +
> >   * Otherwise, patch files matching +<packagename>-*.patch+
> >     are applied in alphabetical order.
> > -  So, to ensure they are applied in the right order, it is hightly
> > -  recommended to named the patch files like this:
> > +  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'.
> >
> > +. If +BR2_GLOABL_PATCH_DIR+ is defined, the directories will be
> > +  enumerated in the order they are specified for patches. The patches
> 
>   I think the "for patches" here is meaningless.

Agree.

Thanks,
-Ryan

[...]

[Buildroot] [PATCH v3 2/2] manual: update for multiple global patch dirs

[Ryan Barnett]

Arnout, All

Ryan Barnett <rjbarnet@rockwellcollins.com> wrote on 12/15/2013 02:01:02 
PM:

> Arnout Vandecappelle <arnout@mind.be> wrote on 12/13/2013 11:19:54 AM:

[...]

>>   Actually, BR2_LINUX_KERNEL_PATCH also supports downloading the patch, 

>> which is not possible with BR2_GLOBAL_PATCH_DIR. As to the others, I 
>> think these options should just be removed (not deprecated, but really 
>> removed, with a clear explanation in Config.in.legacy). And in that 
case 
>> this paragraph becomes redundant.
> 
> I will make note of the BR2_LINUX_KERNEL_PATCH supporting the 
downloading 
> of the patch and that is the only way that it should be used. However, I 

> would rather submit a separate patch series to deprecate the other 
> options. Is this OK with you?
 
I was taking a look at the BR2_LINUX_KERNEL_PATCH option and it appears 
that these patches are applied as a post hook in the patching step. Since 
the advantage with this option is that it supports downloading the patch, 
then I believe you would want these patches to be applied before any user 
patches that would be BR2_GLOBAL_PATCH_DIR. The best example I think of 
for using both BR2_LINUX_KERNEL_PATCH and BR2_GLOBAL_PATCH_DIR is with the 
RT patch. In the RT case, you would want the RT patch to be applied before 
the BR2_GLOBAL_PATCH_DIR.

Would it be acceptable with the patch set to deprecate the option package 
PATCH_DIR options, to make BR2_LINUX_KERNEL_PATCH a pre hook instead of a 
post hook?

Thanks,
-Ryan

[...]