On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
> I'm not /entirely/ sure what the difference is as I'm not in the
> Qt/RCC world too often these days (alas !), but why just not use
> SOURCE_DATE_EPOCH *iff* it is exported?
>
> Normal systems simply do not have this envvar set, so there is really
> no danger of it leaking elsewhere or causing unintended side-effects.
We don't know how application users are using this.
The following is some theoretical example, that I'm quite sure could be used
in some real world applications:
QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in the
ancient past
QFileInfo systemfile("/usr/share/foo/data.xml");
if (systemfile.lastModified() > embeddedFile.lastModified())
{
data = "" />
}
else
{
data = "" />
}
If S_D_E gets used, rather than the data.xml modified date in the source, this
will end up using the wrong file if S_D_E is newer than the system copy of the
file.
This is not a unused databit, but a fully available piece of metadata for the
files.
I'm afraid Sune is right here, it might be used that way. Questionable? Sure thing, but still valid code.
But after all the same can be said from embedding translations into the binary itself.
So yes, we will need help from upstream with this one.