On Wed, 27 Jan 2016, Karl Palsson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Schultz <[email protected]> wrote:
Guillermo,
It's always best to use a custom package if you can. Modifying
upstream leads to problems like this.
I don't think you'd need those changes in uci-defaults.sh.
Instead, I think you should put your changes in your own
uci-default, like 02_network, but your own. Use a number after
02, like 03_custom and put it in /etc/uci-defaults. It should
run on first boot. As long as this uci-default script completes
successfully, I think the change should occur and the script
itself should be deleted so it doesn't run again.
Along these lines, I've tried putting in something like
80_mystuff, where I want to set some configurations options for
various packages that depend on the hardware they're running on.
However, the uci-defaults files are run in alphabetical order, so
while 80_mystuff might come after the 01_leds, 02_network stuff
from core OpenWrt, the uci-defaults files from packages normally
don't seem to have a numerical prefix. This then means that my
80_mystuff script tries to set a config option in a file that
doesn't exist yet.
Now, yes, I can have my 80_mystuff script go and try and create
the package config files it might want to modify, but really, I
want "mystuff" to run _last_ or at least, after all the packages
have run. Is there any better system for this other than just
naming my script zzzzz_mystuff instead of 80_mystuff? Is that
expected to be "good enough" ?
I'm trying this, because I've _been_ trying to use packages
instead of modifying upstream, but when I want my package to do
different things for different targets, it's seemed easier to
hook into the existing target code, rather than trying to copy
target detection and config into a package Config.in options
typically people use 99stuff and figure that the order of 99s doesn't really
matter much
the other thing is that I believe that rc.local gets run out of the very last of
the numbered items, so you can put stuff there.
David Lang
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
