Note: in case we do not agree on this topic this will be the text I'll send to the tech-ctte.
Let me start by noting that I have nothing against reproducibility. In fact quite the opposite: I love the idea... as long as it's properly implemented. The problem here is that __FILE__ is a public, well defined API with very valid use cases (more on this below), even if the current implementation of all the major compilers go against reproducibility. So if we want to mangle __FILE__ (thus breaking API) this should be done by an opt-in, and **never** by opting out. Else we risk breaking a valid implementation, be it already on the archive any new package added afterwards. Even more: we library maintainers continuously ask our upstreams to keep their API as stable as possible, and if not possible following some rules (SONAME change, for example). I will present an option to do the same ourselves without breaking API/ABI. # __FILE__ is a public, well defined API During the course of #876901 many reasons were used to both say that __FILE__ is or not a well defined API. In fact one of the evidences used where the compiler's documentation. For example https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html (enphasis mine): This macro expands to the name of the current input file, in the form of a C string constant. **This is the path by which the preprocessor opened the file**, not the short name specified in ‘#include’ or as the input file name argument. For example, "/usr/local/include/myheader.h" is a possible expansion of this macro. This definition says that it's up to the preprocessor to define the path. So, what has been the behaviour of all major compilers during all these years? Using the full path. The proof of this is Qt itself. Check https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-2/src/testlib/qtestcase.h/#L216 This code has been working on **every** platform Qt works without any change. Qt is compiled in a myriad of OSs, using a myriad of compilers. They all do the exact same thing. So developers depend on a very stable definition of an API. And we all know that breaking API is bad, except if done carefully (read below). # Doing the right thing This is just an idea of "doing the right thing", like bumping SONAME on a library. It definitely doesn't have to be the only one. I understand that the reproducibility people do not want to consider providing the same build path. While this is arguable I do understand that reproducibility without depending on the build path is a good thing. So I've tried to come up with a path to achieve this. ## New macro and warning (if they do not exist already) This would be the first step. The idea is to provide a new macro that, by definition and documentation, it can be mangled with the help of the build system, much as you are currently doing with __FILE__ now. The second step in this is to make compilers create a reproducibility warning if some code uses __FILE__. This will have three effects effects: - discouraging it's use - creating awareness on reproducibility. - making other distros jump into reproducibility in a much easier way. ## Mangling by opting-in, or what to do in the meantime Of course we want to make things reproducible as fast as possible too. This is why mangling __FILE__ was considered and implemented. But this is breaking API, no matter how you look at it. But that doesn't means it can not be used: if a package can be built mangling __FILE__ in order to get a reproducible way then the maintainer should really consider opting *in* for the change, but never ever should the maintainer be forced to opt *out* using a broken API. In fact I consider all the "fixes" of opting in a bug, and forcing this change a couple of weeks before freeze even worse. So I propose you to undo the change in dpkg and, after the release, starting to work on letting maintainers opting in. Regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-talk
