[Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Markus Mayer via buildroot]

Introduce the environment variable BR_PATCH_ARGS as a means for the
caller to pass additional arguments to the patch(1) command. These
arguments can be new arguments not originally used -- or they can
override one of the default arguments.

In addition, provide a mechanism to add patch parameters on a
per-package basis using the <PACKAGENAME>_PATCH_ARGS makefile variable,
for example "PROCPS_NG_PATCH_ARGS". This allows individual packages to
specify extra arguments or override defaults while not affecting any
other part of the build environment.

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
 package/Makefile.in              | 4 +++-
 support/scripts/apply-patches.sh | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/package/Makefile.in b/package/Makefile.in
index 829636900ba9..9df66670c8d3 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -256,7 +256,9 @@ endif
 INSTALL := $(shell which install || type -p install)
 UNZIP := $(shell which unzip || type -p unzip) -q
 
-APPLY_PATCHES = TAR="$(TAR)" PATH=$(HOST_DIR)/bin:$$PATH support/scripts/apply-patches.sh $(if $(QUIET),-s)
+APPLY_PATCHES = TAR="$(TAR)" PATH=$(HOST_DIR)/bin:$$PATH \
+	BR_PATCH_ARGS=$($(PKG)_PATCH_ARGS) \
+	support/scripts/apply-patches.sh $(if $(QUIET),-s)
 
 HOST_CPPFLAGS  = -I$(HOST_DIR)/include
 HOST_CFLAGS   ?= -O2
diff --git a/support/scripts/apply-patches.sh b/support/scripts/apply-patches.sh
index 2acaa63e9fd3..26e7a4a37bb1 100755
--- a/support/scripts/apply-patches.sh
+++ b/support/scripts/apply-patches.sh
@@ -116,7 +116,8 @@ function apply_patch {
         exit 1
     fi
     echo "${path}/${patch}" >> ${builddir}/.applied_patches_list
-    ${uncomp} "${path}/$patch" | patch -F0 -g0 -p1 --no-backup-if-mismatch -d "${builddir}" -t -N $silent
+    ${uncomp} "${path}/$patch" | patch -F0 -g0 -p1 --no-backup-if-mismatch \
+		-d "${builddir}" -t -N $silent $BR_PATCH_ARGS
     if [ $? != 0 ] ; then
         echo "Patch failed!  Please fix ${patch}!"
         exit 1
-- 
2.48.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Thomas Petazzoni via buildroot]

Hello Markus,

On Mon, 27 Jan 2025 13:53:54 -0800
Markus Mayer via buildroot <buildroot@buildroot.org> wrote:

> Introduce the environment variable BR_PATCH_ARGS as a means for the
> caller to pass additional arguments to the patch(1) command. These
> arguments can be new arguments not originally used -- or they can
> override one of the default arguments.
> 
> In addition, provide a mechanism to add patch parameters on a
> per-package basis using the <PACKAGENAME>_PATCH_ARGS makefile variable,
> for example "PROCPS_NG_PATCH_ARGS". This allows individual packages to
> specify extra arguments or override defaults while not affecting any
> other part of the build environment.

Thanks for the proposed patch. Do you have some details on the actual
(not theoretical) use-case(s) ?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Markus Mayer via buildroot]

Hi Thomas,

Re-sending, because I just realized the original response (sent on
January 29) didn't go to the mailing list. That was not intentional.

Here goes...

On Tue, 28 Jan 2025 at 13:09, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Markus,
>
> On Mon, 27 Jan 2025 13:53:54 -0800
> Markus Mayer via buildroot <buildroot@buildroot.org> wrote:
>
> > Introduce the environment variable BR_PATCH_ARGS as a means for the
> > caller to pass additional arguments to the patch(1) command. These
> > arguments can be new arguments not originally used -- or they can
> > override one of the default arguments.
> >
> > In addition, provide a mechanism to add patch parameters on a
> > per-package basis using the <PACKAGENAME>_PATCH_ARGS makefile variable,
> > for example "PROCPS_NG_PATCH_ARGS". This allows individual packages to
> > specify extra arguments or override defaults while not affecting any
> > other part of the build environment.
>
> Thanks for the proposed patch. Do you have some details on the actual
> (not theoretical) use-case(s) ?
>
> Thanks a lot!

When we are building our root file systems, we sometimes have to
bundle older versions of certain packages or we want to apply patches
that are being reviewed upstream without having been accepted and we
want to use the same patch for different versions of a package, say
procps-ng or xfsprogs. Under such circumstances, life becomes a lot
easier if you can tell "patch" to use more fuzz when applying a patch
as it'll apply over a wider range of versions while allowing you to
only track a single patch file.

So I can say
    PROCPS_NG_PATCH_ARGS = -F2
and then it'll use "-F2" while applying these patches, but it is
limited to procps-ng and won't cause any side-effects elsewhere.

This is a fairly specific application of this feature that others may
not need quite in this manner, but it can be used in a very generic
way to address different issues. I figured a facility like this might
be helpful to other users as well for this reason.

It can also come in handy for Buildroot as a whole if a version
upgrade or the introduction of a new patch for one of the existing
packages were to suddenly require more fine-tuned parameters for
applying patches.

Regards,
-Markus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Arnout Vandecappelle via buildroot]

On 05/02/2025 17:58, Markus Mayer via buildroot wrote:
> Hi Thomas,
> 
> Re-sending, because I just realized the original response (sent on
> January 29) didn't go to the mailing list. That was not intentional.
> 
> Here goes...
> 
> On Tue, 28 Jan 2025 at 13:09, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> Hello Markus,
>>
>> On Mon, 27 Jan 2025 13:53:54 -0800
>> Markus Mayer via buildroot <buildroot@buildroot.org> wrote:
>>
>>> Introduce the environment variable BR_PATCH_ARGS as a means for the
>>> caller to pass additional arguments to the patch(1) command. These
>>> arguments can be new arguments not originally used -- or they can
>>> override one of the default arguments.
>>>
>>> In addition, provide a mechanism to add patch parameters on a
>>> per-package basis using the <PACKAGENAME>_PATCH_ARGS makefile variable,
>>> for example "PROCPS_NG_PATCH_ARGS". This allows individual packages to
>>> specify extra arguments or override defaults while not affecting any
>>> other part of the build environment.
>>
>> Thanks for the proposed patch. Do you have some details on the actual
>> (not theoretical) use-case(s) ?
>>
>> Thanks a lot!
> 
> When we are building our root file systems, we sometimes have to
> bundle older versions of certain packages or we want to apply patches
> that are being reviewed upstream without having been accepted and we
> want to use the same patch for different versions of a package, say
> procps-ng or xfsprogs. Under such circumstances, life becomes a lot
> easier if you can tell "patch" to use more fuzz when applying a patch
> as it'll apply over a wider range of versions while allowing you to
> only track a single patch file.

  That's exactly what you *don't* want. With fuzz, the risk is too great that 
the patch _seems_ to apply while it actually doesn't.

  The proper way is to put patches in version directories for each specific 
version you want to support. Yes, it means you have to "manually" rebase the 
patches for each version (but you can script that). But you're anyway _somehow_ 
going to have to check that the patches really apply to that version.


> So I can say
>      PROCPS_NG_PATCH_ARGS = -F2
> and then it'll use "-F2" while applying these patches, but it is
> limited to procps-ng and won't cause any side-effects elsewhere.

  Why would you want to support multiple versions of procps-ng?

  Regards,
  Arnout

> 
> This is a fairly specific application of this feature that others may
> not need quite in this manner, but it can be used in a very generic
> way to address different issues. I figured a facility like this might
> be helpful to other users as well for this reason.
> 
> It can also come in handy for Buildroot as a whole if a version
> upgrade or the introduction of a new patch for one of the existing
> packages were to suddenly require more fine-tuned parameters for
> applying patches.
> 
> Regards,
> -Markus
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] support/scripts/apply-patches.sh: introduce envvar BR_PATCH_ARGS

[Markus Mayer via buildroot]

On Wed, 5 Feb 2025 at 11:28, Arnout Vandecappelle <arnout@mind.be> wrote:
> >
> > When we are building our root file systems, we sometimes have to
> > bundle older versions of certain packages or we want to apply patches
> > that are being reviewed upstream without having been accepted and we
> > want to use the same patch for different versions of a package, say
> > procps-ng or xfsprogs. Under such circumstances, life becomes a lot
> > easier if you can tell "patch" to use more fuzz when applying a patch
> > as it'll apply over a wider range of versions while allowing you to
> > only track a single patch file.
>
> That's exactly what you *don't* want. With fuzz, the risk is too great that
> the patch _seems_ to apply while it actually doesn't.
>
>  The proper way is to put patches in version directories for each specific
> version you want to support. Yes, it means you have to "manually" rebase the
> patches for each version (but you can script that). But you're anyway _somehow_
> going to have to check that the patches really apply to that version.

Generally true, but it also depends. There can be specific situations
(on a per-package basis) where the patch is very simple (just a few
lines) when life becomes easier if you don't have to maintain a patch
for each version. This isn't meant as the main solution to all
problems. It is intended as an option to use when it makes sense.

> > So I can say
> >      PROCPS_NG_PATCH_ARGS = -F2
> > and then it'll use "-F2" while applying these patches, but it is
> > limited to procps-ng and won't cause any side-effects elsewhere.
>
>  Why would you want to support multiple versions of procps-ng?

Because that is how our build environment can end up working out. If,
for some reason, a particular version of a software is needed (while
all the rest is recent), we need to be able to do that, and it can be
easier to maintain if you don't need different versions of the same
patch.

What also happens is that development takes place on the most recent
official release (currently that's 2024.11) while nightly test-builds
also try out what'll happen with buildroot/master. If I need to patch
something, I'll ideally want that patch to apply to the latest release
and the current development tree. (And yes, such patches will
generally be sent upstream, but until they are applied and a new
release is cut, the local patch has to remain.) The need for the patch
to apply to two different versions of Buildroot goes away when the
next release comes out, so the feature might also be handy temporarily
during a development cycle.

In the end, this is meant as a facility to be used sparingly while
being aware of what you are doing. Of course there will always be a
way to resolve any issues without resorting to this feature. I just
find that this can be handy at times – and maintainers can always
ensure it isn't being abused to hide a problem that should be solved
in a different way.

Regards,
-Markus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot