Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
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/
Reply to: