Does Luci support LINUX style .d configuration directories? If it did, site specific changes could be concentrated, and classified in .d directories and there would be a better chance that changes would not make necessary changes from different issues in the same file, and also it would limit the necessity of changes to the main configuration files with an upstream upgrade! I believe the main configuration should include the (by default empty) .d directories by default, so that site specific changes could be made without modifying the upstream configuration files. I am not an expert, so there is probably something wrong with this simple minded idea? 
What do you think?
I suppose if the .d directories are not supported, one should do a backup to a local site maintainers directory which is served by .git. Then after every upgrade, a 3 way merge could be done to find the best compromise between the changes, then a restore could be done. Perhaps this is a better way. Do all openwrt site maintainers know .git? Thank You.
Which of main configurations need additional .d directory? Whats the percentage of routers having space and ram to run git?
I am not sure. That is why I asked the Question.
Openwrt is requiring a huge amount of memory and file space these days. But I think router space for router specific tasks, not maintainer convenience. That is why I am suggesting that the .git stuff be done on some non-router computer. With input data coming from backup and output with restore. If .git were put into openwrt, it would have to be maintained. I can think about better uses for openwrt maintainers' time. .git must exist on the various platform distros, so there is no extra work needed there.
No, LuCI (or rather the underlying uci system) does not support .d directories. Even if it would, it's not clear how to handle them. E.g. when writing a new setting, where should it end up? In the base config? In a new file within .d/ created by LuCI (uci), in the file the option was defined first?
In a way, you can already extract deltas by diffing /rom/etc/config/* against /etc/config/ but this only goes so far, as some files such es network and wrireless are entirely generated from scratch on first boot.
However, once concepts like "site specific configuration" come into play, one could argue that this is a case for central configuration management anyway, and that most likely no LuCI based configuration would be done on individual nodes.
From an implementation perspective, the good thing is that all access to /etc/config/ is happening through libuci so if one would want to implement support for partial settings in .d directories, it could be done centrally in libuci without having to change existing users.
Without extending the underlying API (and all users of it), it would be hard to properly use .d in config write scenarios though, e.g. whether to pool local changes in a single .d/ file (which one?) whether to prefer rewriting base configs, how to handle option and section deletions (just remove from partial file, remove from base config too) and how to handle conflicting settings (e.g. which one to prefer if a given setting is present in base file and two different partials).
1 Like
It goes without saying that if the .git method I suggested were used, (I am not recommending it, only suggesting it as a hypothesis, no experience yet), the .git should be locally hosted, not publicly hosted. You would not want to inadvertently publish any info that should be private. i.e. Don't use GITHub for this plan!
In a way, you can already extract deltas by diffing
/rom/etc/config/*against/etc/config/but this only goes so far, as some files such es network and wrireless are entirely generated from scratch on first boot.
Does this mean that /rom/etc/config was the way the system was at sysupdate and that /etc/config is the way it is now, with your local edits? If so, it would be a good way to initialize your git setup. You could have one branch for the edits coming from your upstream, and another for edits coming from your local site. Sort of like the way some package management setups work. You might even be able to use the same software!
The files completely automatically generated should not be put under .git control.
You are giving me ideas.
But doing it this way would be completely beyond Joe Sixpack! It took me a long time to figure out using .git under some package management schemes.
See here: