Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Explicitely CCing my bug, since it seems it missed my previous reply.

On Fri, 8 Jan 2021 at 20:49, Guillem Jover <guillem at debian.org> wrote:
>
> On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> > [snip]
> > > We did a full archive rebuild testing this change, and I provided
> > > patches to all known affected packages several months ago. It is a
> > > one-line change in debian/rules in most cases:
> > >
> > >   https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org&tag=fixfilepath
> > >
> > > It seems there are less than 10 packages left that have not applied the
> > > patch.
> > >
> > > Longer-term, it would be nice to be able to fix QFINDTESTDATA to be
> > > compatible, sure.
> >
> > >From a couple of "fixes":
> >
> > -export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> > +# Disable fixfilepath feature, as it triggers build failures when
> > +# enabled.
> > +export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
> >
> > That's not a fix but hiding the dirt under the carpet. You are not
> > fixing the root issue nor the reproducibility one.
>
> I'm not sure I understand this objection. Reverting the patch from
> dpkg would do the same but at a global scale, which would make many
> packages that would benefit from the new default, not reproducible,
> and would still "hide the dirt under the carpet" for the very few
> that would otherwise need the option disabled.

__FILE__ has defined behaviour: the path the preprocessor finds. The
only place where __FILE__ is mangled, to the best of my knowledge, is
Debian. So expecting that any developer out there makes code that runs
with this Debian specific variation is unreasonable. In other words:
breaking perfectly valid code *by default*, even in the name of
reproducibility, is not right.

>
> Disabling this option in these few places gives you room to possibly
> look for a fix, or not, w/o the pressure of the freeze, while not
> affecting the other packages.

But still breaking perfectly valid code.


> As stated in the thread in d-d, I still fail to see the weight of the
> objections, TBH. And given this I'm planning on closing the bug in
> dpkg.

In that case we at least should agree that we disagree, so I would ask
the tech-ctte to review this case.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/