[LEDE-DEV] replacing files in base system from a package?

[Zefir Kurtisi]

On 11/25/2016 08:14 AM, Rafał Miłecki wrote:
> On 16 October 2016 at 01:04, Jo-Philipp Wich <jo at mein.io> wrote:
>> let me introduce a not strictly new way but another heavily under
>> documented buildroot feature which you can use to implement custom
>> modifications to packages which do not require source code edits.
>>
>> For every processed package Makefile, the buildroot tries to include a a
>> Makefile fragment in $(TOPDIR)/overlay/*/$(PKG_DIR_NAME).mk which one
>> can use to monkey-patch internals without directly touching the package
>> recipes.
>>
>> For example to amend "base-files" to include a custom banner and
>> inittab, you could create an overlay file called
>>
>>   "overlay/my-example-organization/base-files.mk"
>>
>> which extends the default Package/base-files/install recipe to copy your
>> custom files in the end.
> 
> I'm not exactly sure what's the gain from using this method. Normally
> I need to fork LEDE repo and modify package/base-files/Makefile. With
> your solution I need to fork LEDE repo and add
> overlay/my-example-organization/base-files.mk. Both cases require
> forking LEDE, maybe with overlay it's just easier to track
> my-example-organization changes if you can't use git.
> 
> I think a perfect model for organization/company that wants to be LEDE
> friendly would be to:
> 1) Ask them for complete LEDE-upstream support for their device
> 2) Handle all modifications using an own feed with their packages
> 
> This is a pretty clean situation when we know no extra
> kernel/main-packages modifications are needed to get device working.
> I'd expect overwriting e.g. banner to happen withing sth like
> my-example-organization-base-files package.
> 
> 
We had the approach you describe for a long time (company-basefiles adding to and
overwriting files in base-files package), but this does not work any more. With
recent build-system changes you can't have the same rootfs file in two different
packages (build step fails). Which is good and sane - otherwise you run into
inconsistencies when base-files is installed after company-basefiles.

This overlay approach makes sense for our case, where the things we overwrite are
not common (or good) enough to get them upstream.

Ideally the build-system would also support per-package overlay patches to keep
upstream packages completely untouched - something I looked into but did not get
working so far.


Cheers,
Zefir