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/
signature.asc
Description: This is a digitally signed message part.