On 2017-04-17 19:33, Philip Prindeville wrote:
> I considered editing the Makefile for the package, but then I have
> to update the patch every time the package is updated in LEDE/OpenWRT.
>
> That’s work, and maintaining my own feeds is even more work, since I
> don’t get the benefit of automatically picking up fixes from LEDE or
> OpenWRT (but instead have to do merges/rebases periodically).
>
> What about having a file like $(TOPDIR)/customize.mk which we could
> -include… and it could have things like:
>
> define package/base-files/pre-hook … endef
>
> define package/base-files/post-hook … endef
>
>
> and we could check for such variables being defined, and if they
> are, call them with macro expansion.
>
> If you want to customize /etc/banner for instance, to brand it to
> your build, there should be a trivial way to do this. Editing Makefiles and
> maintaining package feeds are definitely not trivial.
>
> And besides, the justification for killing the Build/IncludeOverlay
> was that "is very likely hard to maintain later”… yet we’ve replaced one
> mechanism which was “hard to maintain” for another one which is every
> bit as much of an effort to maintain, and very likely an ongoing effort.
> At least the Build/IncludeOverlay stuff was nicely compartmentalized so
> it didn’t need any ongoing maintenance effort.
If you just want to brand a build, why don't you simply create your own
package which ships a full /etc/banner via
define Package/<yourpackage>/install-overlay
$(CP) ...
endef
That way you can overwrite existing packages without having to go
through the nastiness of injecting code into existing makefiles.
- Felix
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
