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

[Arnout Vandecappelle via buildroot <buildroot@buildroot.org>]

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