* [Buildroot] External BR overriding upstream packages
@ 2026-01-07 13:55 Andrew Barnes
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Barnes @ 2026-01-07 13:55 UTC (permalink / raw)
To: buildroot
[-- Attachment #1.1: Type: text/plain, Size: 1879 bytes --]
External BR projects can curate their own packages, but they can't easily
modify a package if it already exists upstream.
Ideally such modifications should be made to buildroots package and
upstreamed.
but if the modification is not to be accepted upstream, then we need
another way.
Real examples for just one project i'm working on:
1. downgrade libinput version (Touch screen doesn't work with later
versions, pending investigation)
2. mesa3d - enable legacy api for wpewebkit/cog (wpewebkit will be adopting
the new mesa3d api soon)
3. odd fix for getting QT6 to compile (raised already in mailing list,
could be an upstream patch)
4. complete instrumentation of wpewebkit options (unsure if is worth
upstreaming, will discuss it later)
All these changes can be managed as patches that are applied ontop of BR,
once the changes stablise that can work too.
However, in an IRC discussion, I suggested it could be that BR allows
duplicate packages, and uses the version from the external project instead
of the internal one.
here is a patch to do that:
diff --git a/Makefile b/Makefile
index ff25027c13..efb577b2b2 100644
--- a/Makefile
+++ b/Makefile
@@ -532,7 +532,11 @@ ifneq ($(PACKAGE_OVERRIDE_FILE),)
-include $(PACKAGE_OVERRIDE_FILE)
endif
-include $(sort $(wildcard package/*/*.mk))
+EXTERNAL_PACKAGE_MKS = $(foreach dir,$(BR2_EXTERNAL_DIRS),$(wildcard
$(dir)/package/*/*.mk))
+EXTERNAL_PROVIDED_PACKAGES = $(sort $(notdir $(patsubst %/,%,$(dir
$(EXTERNAL_PACKAGE_MKS)))))
+BUILTIN_PACKAGE_MKS = $(filter-out $(addprefix package/,$(addsuffix
/%,$(EXTERNAL_PROVIDED_PACKAGES))),$(sort $(wildcard package/*/*.mk)))
+
+include $(BUILTIN_PACKAGE_MKS)
include boot/common.mk
include linux/linux.mk
Happy to turn this into a proper patch email, I haven't done that this time
because I think it's more for interest than a serious suggestion.
Kind regards,
Andy
[-- Attachment #1.2: Type: text/html, Size: 2169 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [Buildroot] External BR overriding upstream packages
[not found] <mailman.8084.1767808015.2009750.buildroot@buildroot.org>
@ 2026-03-09 7:19 ` Andreas Ziegler
0 siblings, 0 replies; 2+ messages in thread
From: Andreas Ziegler @ 2026-03-09 7:19 UTC (permalink / raw)
To: Andrew Barnes; +Cc: buildroot
Hi Andy, ALL
Definitely an interesting idea.
On 2026-01-07 13:55, Andrew Barnes wrote:
>
> External BR projects can curate their own packages, but they can't
> easily
> modify a package if it already exists upstream.
I use a lot of overlays for existing Buildroot packages. Things like
checking dependencies, deleting unnecessary files or modifying content
in the target root filesystem are mostly done from hooks defined in
these overlays.
> Ideally such modifications should be made to buildroots package and
> upstreamed.
> but if the modification is not to be accepted upstream, then we need
> another way.
>
> Real examples for just one project i'm working on:
> 1. downgrade libinput version (Touch screen doesn't work with later
> versions, pending investigation)
> 2. mesa3d - enable legacy api for wpewebkit/cog (wpewebkit will be
> adopting
> the new mesa3d api soon)
> 3. odd fix for getting QT6 to compile (raised already in mailing list,
> could be an upstream patch)
> 4. complete instrumentation of wpewebkit options (unsure if is worth
> upstreaming, will discuss it later)
5. I am currently confronted with a package requiring mbedtls-4.
> All these changes can be managed as patches that are applied ontop of
> BR,
> once the changes stablise that can work too.
>
> However, in an IRC discussion, I suggested it could be that BR allows
> duplicate packages, and uses the version from the external project
> instead
> of the internal one.
>
> here is a patch to do that:
>
Ideally, only _complete_ external packages should be filtered, something
like this:
> diff --git a/Makefile b/Makefile
> index ff25027c13..efb577b2b2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -532,7 +532,11 @@ ifneq ($(PACKAGE_OVERRIDE_FILE),)
> -include $(PACKAGE_OVERRIDE_FILE)
> endif
>
> -include $(sort $(wildcard package/*/*.mk))
+define _is_complete
+ $(shell grep -q '\$$(eval \$$([a-z]*-package))' $(1) && echo $(1))
+endef
> +EXTERNAL_PACKAGE_MKS = $(foreach dir,$(BR2_EXTERNAL_DIRS),$(wildcard
> $(dir)/package/*/*.mk))
+COMPLETE_PACKAGE_MKS = $(foreach file,$(EXTERNAL_PACKAGE_MKS),$(call
_is_complete,$(file)))
> +EXTERNAL_PROVIDED_PACKAGES = $(sort $(notdir $(patsubst %/,%,$(dir
> $(COMPLETE_PACKAGE_MKS)))))
> +BUILTIN_PACKAGE_MKS = $(filter-out $(addprefix package/,$(addsuffix
> /%,$(EXTERNAL_PROVIDED_PACKAGES))),$(sort $(wildcard package/*/*.mk)))
> +
> +include $(BUILTIN_PACKAGE_MKS)
>
> include boot/common.mk
> include linux/linux.mk
>
>
> Happy to turn this into a proper patch email, I haven't done that this
> time
> because I think it's more for interest than a serious suggestion.
>
> Kind regards,
>
> Andy
Kind regards,
Andreas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-03-09 7:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.8084.1767808015.2009750.buildroot@buildroot.org>
2026-03-09 7:19 ` [Buildroot] External BR overriding upstream packages Andreas Ziegler
2026-01-07 13:55 Andrew Barnes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox