dpkg 1.22.13 implemented a backwards-incompatible change,
violating Policy (which states the default value is most
certainly *not* “no”) and breaking builds of packages.
dpkg (1.22.13) unstable; urgency=medium
- Dpkg::BuildDriver::DebianRules: Change default R³ value to «no».
I’ve confirmed that an explicit “Rules-Requires-Root: binary-targets”
ceteris paribus fixes the build, so the breakage was indeed introduced
by this dpkg change. Please revert it.
Hi, shouldn't this bug be filed instead against debian-policy for not having recorded the (silent) consensus [1] reached between November 2024 and January 2025? [1] https://linux.debian.devel.narkive.com/7bK6YbqZ/mbf-proposing-rules-requires-root-no-being-the-new-default Regards,
Hi! This was proposed, coordinated in debian-devel and debian-release, and a MBF done, and then the changed was deployed: https://lists.debian.org/debian-devel/2024/11/msg00535.html https://lists.debian.org/debian-devel/2024/12/msg00029.html https://lists.debian.org/debian-devel/2024/12/msg00358.html https://lists.debian.org/debian-devel/2025/01/msg00022.html https://lists.debian.org/debian-release/2024/12/msg00435.html https://lists.debian.org/debian-release/2025/01/msg00028.html https://lists.debian.org/debian-release/2025/01/msg00203.html While the work to make packages build w/o root has been going on for years now, with the conditions where this applies having been tightened increasingly over time, culminating in this change. In this case policy is just lagging, #1092193 (in general policy is not prescriptive, it follows practice). Is this with an out of archive package? If so dpkg-deb should have warned about the problem, otherwise this was then probably missed in one of the mass rebuilds, but I'd be happy to try make this change more smooth. I was pondering about perhaps adding a NEWS entry in the dpkg-dev package, although that still does not help with CI systems and similar. (That's why I'm not closing this right away.) There is also #1092193, which I need to come back to, but in my mind this would be more in the direction as mentioned above, of trying to give better notice or similar. This was already filed, ah, and the change is already in the «next» debian-policy branch, commit 7ef35446b3e7ec8fcb823924d160fa2b168a77c9. Thanks, Guillem
Hi Guillem, [..] From what I can tell from other mails, I believe the package in question is openjdk-8 (unstable only); see bug #1095746. BR, Chris (driving by)
Hi! Ah, thanks for the context. In that case, going by that bug report, it looks like openjdk-8 was most probably already buggy, and this seems like another instance of what was reported in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093766#10 Thanks, Guillem
severity 1095791 serious thanks Yes, it’s one of doko’s originally, and it’s mostly on life support due to many active users. I was unaware of the change due to not having been included in the MBF I only learnt about after reporting the bug on the Fediverse; who knows what other packages are excluded? This also cost me *quite* some debugging, which could have been avoided. It’s still an RC bug in dpkg because Policy specifically says that the default value isn’t “no”, though. Furthermore, this WILL break numerous third-party and downstream distro packages. I consider this a bad change, not only deliberately backwards‐ incompatible, but also SILENTLY changing. If you wanted to have gotten rid of packages not declaring R³ and force package maintainers into even more (usual culprit is lintian) useless churn, go make that an error, but do NOT *ever* change the default value in a backwards-incompatible way leading to silent failures. Plus, you have invented this whole dpkg-build-api thing. Go make that change THERE instead. So, due to the Policy violation, raising severity again. If you want to not have this treated as RC bug, ensure a changed Policy is released first. But I ask you to move the default change to the dpkg-build-api thingy instead. bye, //mirabilos
Hello, Policy has to go through binary-NEW in order to be released. So there isn't a quick fix here. This bug does not count as RC just because Debian upload bureaucracy hasn't been performed yet. There is a clear agreement that the default value has changed. I think the severity should be lowered.
Technicalities. Not looking for one. dpkg should revert this until then. If packagers cannot rely on Policy to give correct information, what *can* they rely on? I’m still in a place where I question this, and diziet apparently also is. This is going to cause untold amounts of headaches in both downstream distro and third-party packages (including organisation- internel ones). dpkg introduced this build api thing. Use that. Or, if you absolutely must cause more useless churn on package maintainers, at least forbid not setting R³. But don’t silently change the default to an incompatible value. bye, //mirabilos
Not really, no. This is not how Debian Policy has ever worked. By that measure packages could not rely on multiarch or triggers to name a coupled of examples. And Policy changes in general tend to be done after the changes have been implemented and deployed in the archive. The problem that triggered this report was only surfaced by the R³ change, but it is not really directly affected by it. The real problem is that the R³ change made it possible to skip calling the «debian/rules build» targets, where the affected package was already Policy buggy, but the breakage was not visible. If the R³ default would get reverted, but the change to call «fakeroot debian/rules binary-arch» kept, the openjdk-8 package would still misbuild. Thanks, Guillem
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. 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 know. Doesn’t change the fact that dpkg’s change breaks packages. Would you *please* at least read and consider the alternative solutions I pointed out above? Thanks. bye, //mirabilos
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: > [...] 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: 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. 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. 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
What about packages that are not in unstable or testing ? Cheers,
Bill Allombert: It is not clear to me what you are asking here. Could you please clarify your question?
Users are using dpkg to build packages that are not part of unstable and testing, and so have not beed considered by the November tests. What will happen to them ? Will they simply FTBFS ? Cheers, Bill.
Hello, It's a little more subtle than this -- Policy is the final arbiter of which packages have Severity:serious in the BTS, and the Release Team is the final arbiter of which of the bugs with Severity:serious count as release-critical for a given release, via their -ignore tags. (Thanks for a helpful reply to this bug, btw.)
Bill Allombert: There is no "Yes/No" answer to this question. The outcome depends on the package in question. Guillem and I identified the failure modes in the preparation for the MBF (see https://lists.debian.org/debian-devel/2024/11/msg00535.html for details). As an example, a `dh` package will generally successfully rebuild without any changes. However, the most common failure more is a FTBFS. It was rare for in-archive packages (2.5%) and I have no reason to believe it would be notably different for out of archive packages. Note this transition only applies to `dpkg-buildpackage` based builds. Any direct use of `dpkg-deb` outside of `debian/rules` (to hand craft debs) is unaffected. Best regards, Niels
Does dpkg-buildpackage -rfakeroot still work as expected ? Is there a command-line flag to dpkg-buildpackage to revert to the bookworm behaviour ? At the very least the way to work-around this should be documented in the release note. Cheers, Bill.
Bill Allombert: As I understand it, that option has always been the way to tell `dpkg-buildpackage` *which* command to use *when* `dpkg-buildpackage` need to invoke something as "root". For me, the relevant aspect here is that the option does not affect the *when* - only which command is used once the condition is met. Within that understanding, the option is still working according to my expectations. The documentation is also aligned with my expectations here. However, you bringing up this option and expectations to it here in this context felt "out of the blue" to me. I suspect you had a entirely different expectation for this option. Therefore, I am hesitant to answer "yes" as long as we are not aligned on expectations. No, there is not and I am not expecting it to materialize either. The `--rules-requires-root` option exists but it is dpkg/1.18 behavior (oldoldoldstable) rather than bookworm behavior. So it is not a perfect match to what you seek (it might be good enough though). If this answer did not satisfy you, please follow up on https://bugs.debian.org/1092193. That bug was filed for discussion whether `dpkg-buildpackage` should have such an option. Guillem has provided a NEWS file for `dpkg-dev` as a way do reach affected parties (uploaded to sid yesterday), which felt sufficient to me. I sense you have a different opinion on this matter than me. I recommend you file a bug against the release notes with the text you would like to see, if you do not feel a NEWS file will do it. Best regards, Niels
Hi! Closing this now. Thanks, Guillem