Source: dpkg
Version: 1.22.13
Severity: serious
Justification: Policy §5.6.31
X-Debbugs-Cc: [email protected]
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.
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
On Wed, 2025-02-12 at 04:16:29 +0100, Thorsten Glaser wrote:
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.
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.)
On Thu, Feb 13, 2025 at 10:50:39AM +0100, Guillem Jover wrote:
On Wed, 2025-02-12 at 04:16:29 +0100, Thorsten Glaser wrote:
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.
[..]
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.)
From what I can tell from other mails, I believe the package inquestion is openjdk-8 (unstable only); see bug #1095746.
From what I can tell from other mails, I believe the package inquestion is openjdk-8 (unstable only); see bug #1095746.
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:
This bug does not count as RC just because Debian upload bureaucracy
hasn't been performed yet.
If packagers cannot rely on Policy to give correct information, what
*can* they rely on?
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.
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.
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.
Control: severity -1 normal
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.
Bill Allombert:
On Mon, Mar 03, 2025 at 08:55:38PM +0100, Niels Thykier wrote:
Control: severity -1 normal
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.
What about packages that are not in unstable or testing ?
It is not clear to me what you are asking here. Could you please clarify
your question?
Bill Allombert:
[...]
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.
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.
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 159:03:04 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,759 |