[LEDE-DEV] [PATCH] base-files: do not backup unchanged files

[Moritz M]

Hi,

However, maybe a configuration backup is not the best way to keep track 
of changes on configuration files.

I get it, but are there better options?

The list of "configuration file" can change as long as their 
configuration are not listed in /lib/upgrade/keep.d.
Backup consists of files listed in /etc/sysupgrade.conf, 
/lib/upgrade/keep.d and changed config files (tracked by opkg).
For example, /etc/firewall.user will not appear in backup if not 
modified (or opkg is missing) because it is not mentioned in
/lib/upgrade/keep.d. There are many more examples. Try yourself:

# find $(cat /lib/upgrade/keep.d/*) -type f -o type l 2>/dev/null | sort 
-u >/tmp/a.txt
# cat /usr/lib/opkg/info/*.conffiles | sort -u>/tmp/b.txt
# diff -u /tmp/a.txt /tmp/b.txt  | grep +

So, even today, it is already expected that a backup after fresh 
installation to have less files than a backup
after some packages where installed. I just made the difference bigger.

Yes I see it. Takes a bit to see how the backup process works ;)

I could add a new option for sysupgrade in order to keep all files 
listed, even those untouched, in order to get the old behaviour.
However, in order to use it, you'll need to call it using a terminal. In 
this case, you could also retrieve those files using ssh+tar, or rsync 
if avaiable.
Anyway, this option would only make sense if I grab also all config 
files mentioned in any installed package, even those untouched.

For me, that would be fine. But on the other hand it is not that often 
that I install new LEDE boxes. And the more I think about it:
I would be ok with the new backup behaviour (just 5 files after fresh 
install). Because those are the only files which are changed on 
installation.


A better fix (that would also be closer to what "normal Linux
distributions" do) would be to reduce the use of /lib/upgrade/keep.d, 
and
instead rely on opkg's config hash tracking for a lot more files (we 
should
make this work without opkg itself first though). This would also work 
with
Moritz's usecase of initial config files supplied in the image build via
/files, as these files would not match the hashes known to opkg.

To me this sounds reasonable but I'm not aware of potential side 
effects.


Moritz