Bug#876901: QFINDTESTDATA uses __FILE__

[Ximin Luo]

Pino Toscano:
> [..]
> 
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>    QFINDTESTDATA)
> 
>> 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:

Myself:
> If all the test files reside underneath the same directory, like tests/, you could:
> 
> 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP:tests=$BASEDIR/tests".
> 
> 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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git