> > So basically squashfs image will be udpated. I am not sure how this > > will work for all the cases. What if application is updated and > > it decides to rename its config file from foo.txt to bar.txt. Now > > when application is launched, user defaults are lost anyway. > I'm in a somewhat middle position. > > Targets are embedded systems and it wouldn't make any sense > to implement a fully flexible update system (deb/rpm/ipkg/...); > I just have two "packages": system and application. > > I *am* the "rootfs (aka: system) image provider". > FYI, I am not a stakeholder. Just chose the "defending" side, to counter Vivek's opinion for the sake of the argument. FYI2, overlayfs maintainer as well as Linux maintainer have always followed the practice of not breaking existing user workloads, so the status quo is playing to your side anyway. I assume, although you did not mention this, that you maintain an OpenWRT derivative. Just so you know, Android is another "system image provider" project whose developers were talking about using overlayfs to provide "debug mode", wherein developers can modify system files. This is the use case for the proposed override_creds=off feature [1]. I do not know if this mode was deployed on existing phones, but anyway, it is not enabled in production mode, so it limits very much the problem of conflict resolution. Thanks, Amir. [1] https://lore.kernel.org/linux-unionfs/20191104215253.141818-1-salyzyn@xxxxxxxxxxx/
