In data lunedì 13 novembre 2017 23:44:00 CET, Ximin Luo ha scritto: > Pino Toscano: > > [..] > > > > This is not an annoyance, it is the crux of the problem! __FILE__ is > > something standard, with a very well defined behaviour, upon which > > people rely on: you cannot trash it from one day to another like this, > > saying "too bad" to all its users, even those using it appropriately. > > It does not simply work. > > > >> but the point is that the previous use does not generalise well. > > > > To be honest: I already said multiple times that abuses of __FILE__ > > *must* be fixed. However, there are valid use cases, and in this case > > the only generalization is done by you, who declared __FILE__ as > > "absolutely BAD". > > > > It's an objective fact that tests using __FILE__ are unable to be > generalised to be run outside of the build.
Yes, and this is already acknoledged. > As Lisandro said in the other comment, "We do *not* want to run the > tests outside the build." This refers to Qt tests, and those using QFINDTESTDATA in particular, for reasons I already explained in another reply. > >> It's not a sledgehammer solution, it's tweakable and we can try to > >> use its flexibility to un-break your tests. > > > > No, it *is* a sledgehammer solution, since you are not even checking > > what __FILE__ is used for, and thus blindly changing it without any > > pre-research on its effect. Again, this is not the correct approach > > to fix the issue at hand. > > > > There are quite a lot of packages that use __FILE__ so forgive me for > not checking every single use-case of it. This. When something is used so widely, then changing its behaviour blindly is simply a no-no. > My patch fixes 1800 packages, and the amount of extra FTBFS it caused > (such as this) is a blip in the stats, and a very minor one at that - > failing tests, because a file was not found. Using statistics to justify a bad behaviour change like this is not a good way to go. This "blip is the stats" ought to show you the behaviour change broke *valid* use cases; also, this does not account how many packages build, but will fail to work at runtime because of this. > (Yes it is RC, but technically it is minor and very easy to fix, but > you're denying us the fix because you seem to feel that the standards > are on your side. To be honest, the only denial I see is your refusal to acknoledge your behaviour change is a bad regression, and a no-go. > Well let's take a look at the standards: > [...] Even with different wordings, both describe basically the same behaviour. And yes, none of them says that __FILE__ is a full path, but surely for relative paths the combination of $srcdir + __FILE__ will give me the path to the source. > You're forcing us to choose between fixing 1800 packages minus your > QT packages, or fixing nothing. And again, your position here is "black or white": either "we change __FILE__ to our liking", or "we fix nothing". There is the middle ground of fixing misuses, which are *already* bugs floating in packages, regardless of reproducible builds. > I ask you to be slightly less absolutist. I am already. That is why I suggested to fix only what is broken in packages. > The solution I proposed is 1-line and should cause basically no > disruption to anything else. By your own admission above, there are so many usages of __FILE__ that you did not check all of them. OK, but in this case, how do you claim your solution will not break anything else? Just because something else builds, then it does not imply it will run correctly at runtime. Even beside this, this case is one *valid* use case of __FILE__ that breaks your assumptions. > >> If this isn't suitable to you, how else do you suppose we should try > >> to make builds independent of (i.e. not embed) the build path? > >> Suggestions are welcome. > > > > I already wrote it in my email, and I repeat it again: > > > > | No, the solution is: > > | a) *not* break what __FILE__ means > > | b) remove the misuses of __FILE__ in packages (not the case of > > | QFINDTESTDATA) > > > > This will require us to patch hundreds of packages, and isn't > realistic. If "hundreds of packages" misuse __FILE__, then simply *fix them*. Sure, it will require time, energy, etc, but I do not see other ways around that without breaking standard behaviours. It is a bit like gets(): it is old, buggy, and obsolete, so sources using it are buggy already. Then, the proper way to fix them is to switch them to use something else, not to make gets() a no-op in libc. > Please, you try sending hundreds of patches, then I will take your > "solution" more seriously. My *solution* (without quotes) is more realistic than your blind breakage. -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
