Bug#876901: QFINDTESTDATA uses __FILE__

Ximin Luo infinity0 at debian.org
Mon Nov 13 20:03:00 UTC 2017

Pino Toscano:
> [..]
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>> I am not "blaming the user", but pointing to the fact that __FILE__
>> is being used in a surprising way here, which is not good for
>> reproducible builds.
> What I see it is happening here is: you (= people working on
> reproducible builds) see __FILE__, and the problems that arise from its
> abuse; to overcome this issue, you use the sledgehammer solution,
> basically changing what __FILE__ means, and thus breaking even valid
> use cases.  Sorry, but I do not see how this is useful.
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.
>> An analogy would be to write your program to execute something at
>> time "__DATE__ + 30 seconds". This is obviously ridiculous, but works
>> "by accident" if done inside a test case.
> This is clearly a misuse, and thus it must be fixed.  OTOH, the
> comparison with __FILE__ is not appropriate.

Why's it not appropriate? If you ever want to write tests to be runnable outside the build, e.g. with autopkgtest, then you're going to have to not use __FILE__ anyway. (Assuming you install the tests somewhere, rather than running the whole build again.)

I can understand that breaking something that used to work is annoying, but the point is that the previous use does not generalise well. I don't really want to get into holy wars about the definition of "validity", I just ask you to consider generality. For example if you try a program that works fine when compiled natively but doesn't work when cross-compiled, that is a failure to generalise and one can either say "not supported, stop breaking us" or one can try to generalise one's program.

It's not a sledgehammer solution, it's tweakable and we can try to use its flexibility to un-break your tests. So, what do you think of this alternate solution, that I suggested:

> If all the test files reside underneath the same directory, like tests/, you could:
> This should make the tests pass, whilst keeping our "$srcpkg-$version" mapping for the non-test files.

Explanation: the map is parsed right-to-left so the later map will be activated first for files underneath tests/ and this mapping will be applied, rather than the default mapping set by our patched dpkg.

This can be done generically in a build helper or something, rather than per-package.

If this isn't suitable to you, how else do you suppose we should try to make builds independent of (i.e. not embed) the build path? Suggestions are welcome.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Reproducible-builds mailing list