Bug#876901: QFINDTESTDATA uses __FILE__

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 14 de noviembre de 2017 13:45:37 -03 Holger Levsen wrote:
> On Tue, Nov 14, 2017 at 11:34:00AM +0000, Ximin Luo wrote:
> > > Sorry, it is not realistic to force us to have a delta from upstream for
> > > no
> > > direct gain.
> > 
> > None of the solutions I suggested involve patching upstream, they would be
> > done in d/rules.
> "we do not only care about Debian but free software in general" - so how
> to do you propose this should be handled for non Debian, eg rpms or
> plain building from source?
> 
> A Debian only solution for this problem is pretty bad or rather, not a
> real solution.

Please allow me to try to analyze this situation from another perspective, 
much more related to what Holger wrote above.

First of all, I want to emphasize that we Qt/KDE maintainers do see a real 
value in both reproducibilty and (because it was mentioned before) cross 
building efforts.

For the cross part Helmut Grone and Dmitry Schanev have been doing an 
*amazing* work to avoid having to create multiple Qt builds to be able to 
cross build stuff, which would have been much easier but a worse solution for 
everyone.

In the same vein Sune Vuorela has been creating patches *directly* to Qt 
upstream in order to improve reproducibility within Qt. It took time, but 
upstream did undertood the reasons behind them and are now part of our code.

I do understand that wanting to change what __FILE__ means is an interesting 
approach, specially because it solves many issues at once (IIRC ~1800?). But 
it has some drawbacks too:

  - It changes the meaning of a well predefined macro (and as I say before I
    consider this a delta), which can have real valid usages like in our case.

  - It does not expands outside Debian.

  - It does not reinforce the idea of reproducibility to programmers. Other
    solutions to related issues made upstreams know and understand the issue,
    so everybody got a better experience.

Xi: you also mentioned that having to file hundreds of patchs seems 
impossible. Well, it seems so, but it is actually not that necessary. Please 
allow me to explain the idea.

What you can do here is starting by documenting/blogging about bad use cases 
so people have something to read when bugs arrive.

Then go ahead with mass bug filing: announce it in debian-devel first, let 
people get involved, then file whatever amount of bugs is necessary, being 
sure to link the aforementioned doc of the first step.

At this point many bugs will get an upstream bug, patches upstream, developers 
understanding the issue... and many bugs being fixed by other people. Projects 
will get a better source code, all distros can benefit from it an most 
probably eve cooperate by patching their preferred sources upstream.

Drawbacks: it takes much more time. But I think the final result justifies it.

You might wonder if there has been any experience on this before. At least 
from my POV I can say yes. Removing Qt3 in favour of Qt4 did not meant simply 
asking for the Qt3 sources removal but pushing people to do their best to port 
the code. It took us (if I remember correctly) one and a half release.

Removing Qt4 is an effort currently undergoing, which has already taken at 
least three Debian releases. Is it worth the effort? Yes! Because we pushed 
many sources to be ported, thus giving projects a new lifespan, better 
usability, better code...

So yes, it might not sound pretty, but the long road, in my opinion at least, 
is the way to go here. Even if it means filing 1800 bugs.

-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20171114/f09331d8/attachment.sig>