Bug#876901: QFINDTESTDATA uses __FILE__

Pino Toscano pino at debian.org
Wed Nov 15 18:44:50 UTC 2017


In data mercoledì 15 novembre 2017 12:09:00 CET, Ximin Luo ha scritto:
> Lisandro Damián Nicanor Pérez Meyer:
> > [..]
> > 
> > Xi: you also mentioned that having to file hundreds of patchs seems 
> > impossible. Well, it seems so, but it is actually not that necessary. Please 
> > allow me to explain the idea.
> > 
> 
> Thanks for being less inflammatory than Pino.

Flame that you started, mind you.

> I agree that eventually all projects should move away from using
> __FILE__.

Again, why?  Just because __FILE__ gives results that break
reproducibility does not mean that it is wrong/bad -- the topic of this
bug is exactly one of the cases where it *does* make sense to use
__FILE__.

> This BUILD_PATH_PREFIX_MAP variable is only a stepping stone to that,
> just like SOURCE_DATE_EPOCH was a stepping stone to less projects
> using __DATE__ and __TIME__. It allows people to see the obvious
> benefit of a reproducible build, by actually achieving a large amount
> of reproductions, today. We did not need to file mass bug reports for
> __DATE__ and __TIME__ with SOURCE_DATE_EPOCH.

Again: comparing with __DATE__ and __TIME__ makes no sense, since they
were used in 99+% of the cases only for display purposes.  OTOH, this
thread shows __FILE__ it is not used (only) for that.

> You're implying that QT's use of __FILE__ for tests, as being
> discussed in this thread, is a "good use case"

Exactly, it *is*.

> That's not how I see it. As I pointed out various times already, the
> use of __FILE__ here is *also not appropriate*. You can consider
> these emails from me now, as "documenting/blogging" about "bad use
> cases".

OK, sure, we agree to disagree.  But ...

> In summary: in no document or standard, does it guarantee or imply
> that __FILE__ can be taken to represent a real filesystem path.
> Applications relying on this behaviour are broken and should not be
> upset when things don't work. As documented in multiple places,
> __FILE__ only has a very loose meaning, my patch fits within this
> loose meaning, and it is intended mostly for error messages.

... this is your own interpretation.  Even if __FILE__ has a loose
meaning, you are still changing that small bit of meaning it has,
without even thinking twice.  Also, where it is written that __FILE__
is "only for error messages"?

> The BUILD_PATH_PREFIX_MAP variable works around a lot of "bad use
> cases", but it doesn't cover this particular case. Some minor tweaks
> are needed to cover it, and I suggested them already.

So this is not a solution, but low quality workaround.

> But you guys continue to push the position "we're doing nothing
> wrong, it's other people doing stuff wrong, go talk to them instead".

Let's flip this: you continue to push the position "everybody using
__FILE__ is wrong, I won't listen to anybody".

> I'm sorry but it's not a convincing position for me to agree with.

Neither is yours, sorry.

> At the end of the day, all of these cases, including yours, ought to
> be fixed to not use __FILE__ at all.

Again, we agree to disagree.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20171115/be0c29d1/attachment.sig>


More information about the Reproducible-builds mailing list