On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
> On 28 November 2016 at 09:33, Zefir Kurtisi <zefir.kurt...@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

_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Reply via email to