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

[Guillem Jover]

On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> On 2020-11-14, Sune Vuorela wrote:
> > Unfortunately, only like 10% of the relevant packages have test suites
> > enabled and run, because gettings things to work reliable is sometimes
> > hard.

> So, based on your estimate and the current packages known to be
> affected, Debian might have an additional 300 packages that might
> someday enable test suites. That is ~1% of the archive that would need
> to make a one-line change in debian/rules if the maintainers enable test
> suites for those packages.
> 
> Are there any templates or documentation used for such packages that
> might be able to facilitate the process?

It looks like if this cannot be fixed in the test suite themselves for
now, then refactoring this setting into a dh sequencer could cover it
automatically for all these cases?

> > Adding more hurdles does not help. 
> > I think this is a hurdle we do not need.
> 
> To me, a one-line change in packaging seems like a quite small hurdle in
> the short-term, but clearly you do not agree.

This being just a default change that can be overridden with a one
line modification, seems to me also to be quite unobtrusive. More so
when we have things like hardening that people are overriding all over
the place w/o much of an issue.

> So it really comes down to applying opt-in patches for hundreds (maybe
> thousands) of packages, or an opt-out change for somewhere in the
> ballpark of tens or hundreds of packages.

Yes, that's my view too. I had the patch queued in dpkg for my next
push, but I've pulled it out for now given the raised concern, but
I'm not seeing a very strong case here to not include it again TBH.

> Long-term, of course it would be more ideal to fix QFINDTESTDATA to be
> compatible with -ffile-prefix-map/-fmacro-prefix-map compiler flags
> being used to strip the build path from the compiled outputs; this would
> solve the issue for potentially hundreds of packages and would make the
> issue essentially moot.

Yes.

Thanks,
Guillem