Comment 53 for bug 1650688

I'm pretty much with @ddstreet here, introducing another hack to handle Ubuntu Core quirks is not nice, as those hacks will make our systemd more unstable over time and will break regularly after merging upstream changes.

As stated before, we already carry such hacks since 2014 and I just want to give a brief quote from that long standing patch: "Forwarded: OMGno, this is a rather nasty hack until we fix system-image to get a writable /etc" – I do not know a lot about Ubuntu Core's file system hierarchy and why it deviates from the common setup, but maybe getting a writable /etc is the core problem to solve here, as stated by @pitti in 2014 already.

IIUC we currently have a workaround by @ogra in place that only applies to the "timedatectl" CLI, the proposed MRs would fix this for the "timedatectl" CLI and the systemd-timedated DBus API. But what about other tools that assume /etc/localtime to be handled like on most other common systems? Do we start patching every application now and teach them about Ubuntu Core's /etc/writable quirks, e.g. glibc's "tzset(3)"?
That cannot be the correct path forward...

OTOH those MRs are rather small and clear and they solve an issue for our users NOW (tho only one part of the issue that is related to systemd-timedate).

As a compromise I guess I would be willing to accept the current patches into Jammy (so they can be SRUed afterwards), IF we have a clear path forward about solving this problem properly and replacing the hack with an upstream solution in the not too distant future – hopefully dropping the other long-standing /etc/writable patch at the same time.

The snapd team (Michael/Valentin) recently started investigating proper upstream solutions to this problem (thanks for that!) and I asked Valentin to create a tracking bug for us, that we can reference alongside those new hacks, so we can drop them once a better solution is in place: https://bugs.launchpad.net/snappy/+bug/1953172