Control: severity -1 normal Hi Thorsten
As you can see, I have downgraded the bug to normal. I will come back to my reasons for that below, but I would like to start elsewhere first.
Thorsten Glaser: > On Fri, 14 Feb 2025, Guillem Jover wrote: > [...]
Yes, I know. I’m sorry for having a life in which I needed a quick workaround for this dpkg RC bug in the package first, since that affects actual users, and that it takes time fully analysing what the packaging I only inherited in the first place does wrong, where, and how to best fix it, plus openjdk-8 takes a full day to build on my hardware. (Less with nocheck, sure.)
I understand you feel burned by this change and that was unintended. You have been working hard to maintain packages such as openjdk-8 for the sake of our users. Ideally, I would have correctly identified openjdk-8 as related to this transition. If so, we would filed a bug against openjdk-8 with a heads up about the change along with known solutions. These solutions included the same one-liner that you identified yourself at the start of this thread, which would have avoided the extra effort on your end. Unfortunately, when we build tested openjdk-8 back in November, I failed to see the link between the failure and this transition, so you did not get such a bug report and we are now here. That was my mistake and I am sorry for the frustration it caused you as result.
Thorsten Glaser:
On Fri, 14 Feb 2025, Guillem Jover wrote: [...] That’s for things which Policy didn’t describe yet because they were new. But if Policy states a definite value, I *expect* the tooling to adhere to that value.
You have made your opinion on Policy and the role you feel it has as an authority clear. Several people have voiced their disagreement to this, so for the purpose of this discussion I feel we can only end with a "agree to disagree" on the Policy role as an authority for behavior of tools and packages. As for the RC'ness of this bug, I have downgraded the bug to normal as you saw above. I am doing that since the Release Team are the final arbiter of which bugs are release critical (and not Debian Policy). Since the Release Team have approved the default change for Trixie at my request back in January, I have concluded that its current value is not release critical. If you wish to challenge my interpretation of the Release Team, I feel the proper course of action from you would be to contact the release team with me in CC. Then the two of us can have the discussion with the proper authority on the matter.
[...]I know. Doesn’t change the fact that dpkg’s change breaks packages.
Guillem and I were fully aware that the change would cause FTBFS bugs. This was also why we proposed a MBF in November on debian-devel before deploying the change. We discussed this change in public on debian-devel and I concluded that the project accepted the cost of the change given none of the feedback had objections to the change.
If you believe the project took the wrong decision here, you should raise it on debian-devel. That is where the decision was backed by a project concensus, so I feel the project should be involved in changing it. Not us here in a bug.
Would you *please* at least read and consider the alternative solutions I pointed out above? Thanks. bye, //mirabilos
I mentioned in my MBF that the change was a trade-off. I was going for a short term cost for a long term gain by removing fakeroot from our default build stack. The fakeroot tool has been unreliable at times causing non-root ownership to leak into package builds or causing random build failures. The fakeroot tool also had a history of causing performance issues with how the Debian build stack works. In my view, this will make our build system much more stable going forward and should result in fewer reliability related problems for maintainers down the line.
When Guillem and I analyzed the numbers in November, we concluded we could remove fakeroot from 10 000 packages while only having to fix about 250 packages. That is, only 2.5% of the packages would need a change.
However, the premise for those numbers was that we changed the default in the way we did. The two alternative solutions you proposed would have either failed to deliver the value (using the dpkg-build-api method) or require a lot more work (by requiring an explicit R³ in all packages).
Since those alternatives would not have solved our problem, Guillem and I are not considering them as viable alternatives.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
