Bug#876901: QFINDTESTDATA uses __FILE__
Lisandro Damián Nicanor Pérez Meyer
perezmeyer at gmail.com
Tue Nov 14 14:24:19 UTC 2017
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
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
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.
Lisandro Damián Nicanor Pérez Meyer
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Reproducible-builds