flatpak use of January 1st 1970 as date creates problems for KDE software

[Alexander Larsson]

On Fri, 2020-10-23 at 16:17 -0600, Dan Nicholson wrote:
> On Fri, Oct 23, 2020 at 3:30 PM Albert Astals Cid <aacid at kde.org>
> wrote:
> > 
> > I don't know much about flatpak, but can we make it so the date is
> > not always January 1st 1970 but some of these?
> >  * the date the flatpak was built
> >  * the date the flatpak was installed
> 
> Using the epoch for the modification time for checked out files is
> pretty deeply wired into how ostree and flatpak work. If this was
> changed it would likely have many subtle knock on effects. Here's the
> last time this was tried -
> https://github.com/ostreedev/ostree/pull/330.
> 
> It's possible that flatpak could override that at checkout time and
> update the mtimes to the current time, but I imagine it would cause
> unexpected issues. At the least it would likely cause any caches
> embedded in the commit to be invalidated.

Noticed this late. 

Yeah, the issue is really that ostree does not consider mtime to be
part of the identifying information for the file, beacuse that way more
files can be considered the "same", leading to better sharing between
apps/runtimes/etc. Since all such "shared files" use the same inode
(i.e. they are hardlinked) they must use the same mtime on disk, and
the value 0 was chosen. 

This might not have been the ideal choice (and as seen in the bug link
above we did try to change it once), but at this point it is not
possible to change, because a lot of things (subtly or not) depends on
the exact value.

For example, all the caches (like fontconfig, or compiled python files,
etc) that we ship in the runtimes contain embedded timestamps of the
files they are cached from, and any difference in those break the
caches.