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

[David Lang]

On Tue, 11 Oct 2016, Rafał Miłecki wrote:

> On 3 October 2016 at 15:26, Karl Palsson <karlp at tweak.net.au> wrote:
>> What's the "new" way of doing this? In the past, in OpenWrt CC
>> and before, a package could install files like /etc/banner and
>> /etc/inittab that were provided by the base-files package. It was
>> always listed as "unreliable" as apparently you couldn't rely on
>> the order. In practice it actually worked just fine.
>>
>> Presently, LEDE actively prevents this, with the build scripts
>> failing the build with
>>
>>
>>  * check_data_file_clashes: Package blah wants to install file /home/karlp/src/lede-source/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/etc/banner
>>         But that file is already provided by package  * base-files
>>  * check_data_file_clashes: Package blah wants to install file /home/karlp/src/lede-source/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/etc/inittab
>>         But that file is already provided by package  * base-files
>>  * opkg_install_cmd: Cannot install package blah.
>> package/Makefile:56: recipe for target 'package/install' failed
>>
>> Now, clearly I could just edit the base-files package in a forked
>> repository. However, the motivation of using a package was to
>> avoid forking LEDE. I've seen talks and presentations on this,
>> "use a package!"
>>
>> What's the currently accepted mechanism for including replacement
>> files in a custom build?
>
> From the discussion I can see that there isn't any clean solution for
> that. You can use uci-defaults that will overwrite "default" files or
> just use files subdirectory that doesn't really follow idea of using
> packages for extra software & customizations.
>
> I was thinking about dropping/changing check_data_file_clashes and
> then adding some kind of priority for packages. It would determine the
> order packages are being included on the rootfs. Unfortunately it's
> behind me knowledge to modify rootfs building this way.

I think this is a bad idea, your priority for packages may not match someone 
else's priority, and what happens if someone wants something from one package 
and something else from another.

I could see the ability to say "This package is explicitly designed to override 
files in others" for customization, but unless the /files approach has been 
eliminated, that's a far better approach for local customizations.

David Lang