Re: [LEDE-DEV] replacing files in base system from a package?
On 12/01/2016 10:29 PM, Rafał Miłecki wrote:
> On 1 December 2016 at 12:48, Zefir Kurtisi wrote:
>> On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
>>> 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 /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, > 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.)
>
> I was testing it multiple times, /files/etc/banner
> overwrites one from base-files.
>
You're right. 'prepare_rootfs' is called from image.mk/target-dir-%: _after_
packages have been installed. Which makes /etc/banner overwritten in case you
re-install base-files*.pkg on target.
Then it would be a good idea to at least warn about the potential inconsistency
during build. Or maybe remove copying of $(TOPDIR)/files completely, since the
overlay mechanism is sufficient for any use-case.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 1 December 2016 at 12:48, Zefir Kurtisi wrote:
> On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
>> 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 /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, 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.)
I was testing it multiple times, /files/etc/banner
overwrites one from base-files.
--
Rafał
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
> On 28 November 2016 at 09:33, Zefir Kurtisi 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
> /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 /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, /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 /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
/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
Re: [LEDE-DEV] replacing files in base system from a package?
On 28 November 2016 at 09:33, Zefir Kurtisi 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 /files/ which allows you to e.g. overwrite banner. 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. Shall we detect conflicting files in /files/ as well? It makes sense just like previous change did but I'm still missing some solution for overwriting files without forking LEDE. -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 11/25/2016 08:14 AM, Rafał Miłecki wrote: > On 16 October 2016 at 01:04, Jo-Philipp Wich 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 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 25 November 2016 at 08:14, Rafał Miłecki wrote: > 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. I'm wondering: could we extend one package (e.g. base-files) with another (e.g. my-example-organization-base-files)? The problem I don't know how to solve is directory change as all /install rules use relative paths. So assuming there is: define Package/base-files/install $(CP) ./files/* $(1)/ endef I'd like something like: define Package/my-example-organization/base-files/install cd $(TOPDIR)/package/base-files $(call Package/base-files/install,$(1)) cd $(THIS_PACKAGE_DIR) @echo "Installing cutomized base files" $(INSTALL_DATA) ./files/banner $(1)/etc/banner endef (of course I don't expect my "cd" commands to work) Is this possible to achieve? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 16 October 2016 at 01:04, Jo-Philipp Wich 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. > Assuming a directory structure like this... > > * overlay/my-example-organization/banner > * overlay/my-example-organization/inittab > * overlay/my-example-organization/base-files.mk > > ... the base-files.mk would need to include something like the following > code to splicy your custom files into the packaging procedure: > > --- 8< --- > # Figure out the containing dir of this Makefile > OVERLAY_DIR:=$(dir $(abspath $(lastword $(MAKEFILE_LIST > > # Declare custom installation commands > define custom_install_commands > @echo "Installing extra files from $(OVERLAY_DIR)" > $(INSTALL_DIR) $(1)/etc/config > $(INSTALL_DATA) $(OVERLAY_DIR)/banner $(1)/etc/banner > $(INSTALL_DATA) $(OVERLAY_DIR)/inittab $(1)/etc/inittab > endef > > # Append custom commands to install recipe, > # and make sure to include a newline to avoid syntax error > Package/base-files/install += $(newline)$(custom_install_commands) > --- >8 --- The problem I see with this is placing customizations in a LEDE fork repository. So if one would like to try overlay solution, maybe it'd be better/cleaner to remove files from base-files? define custom_install_commands @echo "Removing files that will be provided customized" rm $(1)/etc/banner rm $(1)/etc/inittab endef Do you think it'd be a sane usage? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
Please revert this patch. This obvious breaks legitimate use cases. On 10/04/2016 12:59 AM, Russell Senior wrote: Fwiw, I ran into trouble with things busybox provides by default, but where I've add packages with fuller versions. In my case it is procps-ng from the packages feed. In order to stop it complaining, I need to de-select the conflicting busybox options. What I've done instead, locally, is just revert this commit: 021b96d7c5c668fbcb5375c65cee90832bb2854f Hopefully, nothing significant breaks as a result. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/28/2016 05:21 PM, Jo-Philipp Wich wrote: > Hi Zefir, > > what do you mean with overlay patches exactly? > > ~ Jo > I mean adding some private patches on top of those already contained in the package's patches directory without touching the package itself. I thought the same overlay mechanism available for overwriting installation files would be easy to implement, but seems a bit tricky. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
Hi Zefir, what do you mean with overlay patches exactly? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/17/2016 11:38 AM, Zefir Kurtisi wrote: > On 10/16/2016 01:04 AM, Jo-Philipp Wich wrote: >> Hi Karl, >> >> 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. >> > Wow! - this really deserves an easier to find documentation - I was looking > for > that feature several times but never got to it. > > We used to have copies of packages for only minor modifications in init or > config > files. If it works as described, this will reduce a lot of overhead. > > > Thank you, very helpful. > > Hello Jo, indeed, it works as described, thanks. Is there some similar mechanism in place for adding overlay patches? >From what I understand one would need to expand Build/Prepare, but it is not obvious (to me at least) how to extend the list of patches. Cheers ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/16/2016 01:04 AM, Jo-Philipp Wich wrote: > Hi Karl, > > 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. > Wow! - this really deserves an easier to find documentation - I was looking for that feature several times but never got to it. We used to have copies of packages for only minor modifications in init or config files. If it works as described, this will reduce a lot of overhead. Thank you, very helpful. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
Hi Karl, 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. Assuming a directory structure like this... * overlay/my-example-organization/banner * overlay/my-example-organization/inittab * overlay/my-example-organization/base-files.mk ... the base-files.mk would need to include something like the following code to splicy your custom files into the packaging procedure: --- 8< --- # Figure out the containing dir of this Makefile OVERLAY_DIR:=$(dir $(abspath $(lastword $(MAKEFILE_LIST # Declare custom installation commands define custom_install_commands @echo "Installing extra files from $(OVERLAY_DIR)" $(INSTALL_DIR) $(1)/etc/config $(INSTALL_DATA) $(OVERLAY_DIR)/banner $(1)/etc/banner $(INSTALL_DATA) $(OVERLAY_DIR)/inittab $(1)/etc/inittab endef # Append custom commands to install recipe, # and make sure to include a newline to avoid syntax error Package/base-files/install += $(newline)$(custom_install_commands) --- >8 --- HTH, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
David Lang wrote: > > 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. Using files is a poor choice: * It requires forking * It can't make decisions based on make variables Both of these are things that in the past were easily met by packages providing files themselves. Sincerely, Karl Palsson signature.asc Description: OpenPGP Digital Signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On Tue, 11 Oct 2016, Rafał Miłecki wrote: On 3 October 2016 at 15:26, Karl Palsson 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___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 2016-10-11 12:38, Rafał Miłecki wrote: On 3 October 2016 at 15:26, Karl Palsson 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? Purely fyi, I also ran into this issue and I'm now using the imagebuilder for overwriting these files afterwards (with the FILES parameter) This way the build order of packages also doesn't interfere. 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. Felix, can we hear your opinion on this, please? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 3 October 2016 at 15:26, Karl Palsson 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. Felix, can we hear your opinion on this, please? -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
> "Karl" == Karl Palsson writes: Karl> What's the "new" way of doing this? In the past, in OpenWrt CC and Karl> before, a package could install files like /etc/banner and Karl> /etc/inittab that were provided by the base-files package. It was Karl> always listed as "unreliable" as apparently you couldn't rely on Karl> the order. In practice it actually worked just fine. Fwiw, I ran into trouble with things busybox provides by default, but where I've add packages with fuller versions. In my case it is procps-ng from the packages feed. In order to stop it complaining, I need to de-select the conflicting busybox options. What I've done instead, locally, is just revert this commit: 021b96d7c5c668fbcb5375c65cee90832bb2854f Hopefully, nothing significant breaks as a result. -- Russell Senior, President russ...@personaltelco.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/03/2016 11:00 PM, Karl Palsson wrote: > Alberto Bursi wrote: >> >> On 10/03/2016 03:26 PM, Karl Palsson 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. >>> >>> What's the currently accepted mechanism for including replacement >>> files in a custom build? >>> >>> Sincerely, >>> Karl Palsson >>> >> What I've found so far for my own project is that a script in >> /files/etc/uci-defaults folder in source folder should work. >> Anyway scripts in /etc/uci-defaults (from any source) are >> called on first boot and apply configuration changes on device, >> just look at the ones you have already there in the rootfs. >> > You're absolutely correct, that way _works_ but it's pointlessly > redundant to ship files just so that I can make the bootup > process take longer while it "finishes" replacing files that I > knew from the outset I never wanted. It also means that until > _my_ uci-defaults file runs, (depends on everyone else) I still > have the old original files in place. uci-defaults is a great > mechanism for many things, but i really don't feel it's > appropriate for everything. > > Sincerely, > Karl Palsson Ehm, I did say what I found and works, not necessarily what is best. I'm also trying to do the same and info is very meh. Anyway did you try adding files in a /files folder you create in the source folder? various sources claim that stuff in /files should theoretically go in the rootfs's / when building the image, so if you make /files/etc/config/myconfig it should go in the right place. according to some posts in openwrt forum it seems to overwrite stock configuration at build time. https://forum.openwrt.org/viewtopic.php?id=22517 But I've not tried that yet in my project so I can't tell. If it works (or not) please tell me as I'm also interested in that. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
Alberto Bursi wrote: > > > On 10/03/2016 03:26 PM, Karl Palsson 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. > > > > What's the currently accepted mechanism for including replacement > > files in a custom build? > > > > Sincerely, > > Karl Palsson > > > > What I've found so far for my own project is that a script in > /files/etc/uci-defaults folder in source folder should work. > Anyway scripts in /etc/uci-defaults (from any source) are > called on first boot and apply configuration changes on device, > just look at the ones you have already there in the rootfs. > You're absolutely correct, that way _works_ but it's pointlessly redundant to ship files just so that I can make the bootup process take longer while it "finishes" replacing files that I knew from the outset I never wanted. It also means that until _my_ uci-defaults file runs, (depends on everyone else) I still have the old original files in place. uci-defaults is a great mechanism for many things, but i really don't feel it's appropriate for everything. Sincerely, Karl Palsson signature.asc Description: OpenPGP Digital Signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/03/2016 03:26 PM, Karl Palsson 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. > > What's the currently accepted mechanism for including replacement > files in a custom build? > > Sincerely, > Karl Palsson > What I've found so far for my own project is that a script in /files/etc/uci-defaults folder in source folder should work. Anyway scripts in /etc/uci-defaults (from any source) are called on first boot and apply configuration changes on device, just look at the ones you have already there in the rootfs. -Albert ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
