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
