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

[Zefir Kurtisi]

On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
> On 28 November 2016 at 09:33, Zefir Kurtisi <zefir.kurtisi at neratec.com> wrote:
>> 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.
> 
> On the other hand build system still allows overwriting files using
> <buildroot dir>/files/
> which allows you to e.g. overwrite banner.
> 
Hm, this was new to me. Skimming through [1], it is not clear what kind of files
should be included here. The example refers to additional configuration files - to
me it looks like it is useful only for files that do not exist in any installed
package elsewhere.

[1] https://wiki.openwrt.org/doc/howto/build

> So you still may end up with base-files installed and /etc/banner
> being different. If you re-install that package, e.g.
> opkg install base-files*.ipk
> you'll get banner changed to package's version.
> 
>From how I understand the scripts ('prepare_rootfs' is called before packages are
installed), a <buildroot dir>/files/etc/banner initially copied into the rootfs
would be overwritten with base-files/files/etc/banner when base-files*.ipk is
installed at the image install step. With that, <buildroot dir>/files/etc/banner
should never make it into a firmware image.

(This is from looking at the include files only, did not test, could be wrong.)

> Shall we detect conflicting files in <buildroot dir>/files/ as well?
> It makes sense just like previous change did but I'm still missing
> some solution for overwriting files without forking LEDE.
> 

Depends. Since this is nowhere specified, one could also argue the files in
<buildroot dir>/files/ are meant as fallback in case no other package is providing
them.

As for overwriting files without forking LEDE - we do it as follows: we have a
super git repository that hosts LEDE.git as a submodule with minor changes on top
of upstream. One of those changes is to have a soft-link from $TOPDIR/overlay to
../overlay where our custom modifications for packages' files are kept.

This allows us to easily follow LEDE development (since rebasing is trivial) and
keep custom modifications to packages in our super repository.


Cheers,
Zefir