El mar., 3 de abr. de 2018 16:42, Sune Vuorela <s...@debian.org> escribió:
> 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 = readFromFile(systemFile);
> }
> else
> {
> data = readFromFile(embeddedFile);
> }
>
> 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.
>
>
