Thanks Amir, comments inline below. On 9/3/20 10:30 AM, Amir Goldstein wrote: >>> 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. I guessed that ;) > 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'm *very* glad to hear this, but if there's any chance this will change in a foreseeable future I'd want to know it *now*, changing later would be a disaster (for me, of course). > I assume, although you did not mention this, that you maintan an > OpenWRT derivative. No, that's a fair guess, but I'm actually rolling out a full system based on Buildroot with current upstreamed u-boot/kernel/apps. > 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. I'm not sure about what You mean exactly, but I'll try to check it if You so suggest. > Thanks, > Amir. > > [1] https://lore.kernel.org/linux-unionfs/20191104215253.141818-1-salyzyn@xxxxxxxxxxx/ Regards Mauro
