Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

[Thorsten Glaser]

Source: dpkg
Version: 1.22.13
Severity: serious
Justification: Policy =C2=A75.6.31
X-Debbugs-Cc: ***@mirbsd.de

dpkg 1.22.13 implemented a backwards-incompatible change,
violating Policy (which states the default value is most
certainly *not* =E2=80=9Cno=E2=80=9D) and breaking builds of packages.

dpkg (1.22.13) unstable; urgency=3Dmedium
- Dpkg::BuildDriver::DebianRules: Change default R=C2=B3 value to =C2=
=ABno=C2=BB.

I=E2=80=99ve confirmed that an explicit =E2=80=9CRules-Requires-Root: binar=
y-targets=E2=80=9D
ceteris paribus fixes the build, so the breakage was indeed introduced
by this dpkg change. Please revert it.

[Guillem Jover]

Control: severity -1 normal

Hi!

Post by Thorsten Glaser
Source: dpkg
Version: 1.22.13
Severity: serious
Justification: Policy §5.6.31
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.

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).

Post by Thorsten Glaser
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.

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.

Post by Thorsten Glaser
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

This was already filed, ah, and the change is already in the «next»
debian-policy branch, commit 7ef35446b3e7ec8fcb823924d160fa2b168a77c9.

Thanks,
Guillem

[Chris Hofstaedtler]

Hi Guillem,

Post by Guillem Jover

Post by Thorsten Glaser
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.

[..]

Post by Guillem Jover
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 in
question is openjdk-8 (unstable only); see bug #1095746.

BR,
Chris
(driving by)

[Guillem Jover]

Hi!

Post by Chris Hofstaedtler

Post by Guillem Jover

Post by Thorsten Glaser
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.

[..]

Post by Guillem Jover
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 in

question 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:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093766#10

Thanks,
Guillem

[Thorsten Glaser]

severity 1095791 serious
thanks

Post by Guillem Jover

Post by Chris Hofstaedtler

Post by Chris Hofstaedtler
From what I can tell from other mails, I believe the package in

question 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

Yes, it=E2=80=99s one of doko=E2=80=99s originally, and it=E2=80=99s 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=E2=80=99s still an RC bug in dpkg because Policy specifically says that
the default value isn=E2=80=99t =E2=80=9Cno=E2=80=9D, though.

Furthermore, this WILL break numerous third-party and downstream distro
packages. I consider this a bad change, not only deliberately backwards=E2=
=80=90
incompatible, but also SILENTLY changing. If you wanted to have gotten
rid of packages not declaring R=C2=B3 and force package maintainers into ev=
en
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
--=20
Yes, I hate users and I want them to suffer.
=09-- Marco d'Itri on gmane.linux.debian.devel.general

[Thorsten Glaser]

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.

That=E2=80=99s for things which Policy didn=E2=80=99t describe yet because =
they
were new. But if Policy states a definite value, I *expect* the
tooling to adhere to that value.

Or, if you absolutely must cause more useless churn on package
maintainers, at least forbid not setting R=C2=B3. But don=E2=80=99t sile=

ntly

change the default to an incompatible value.

The problem that triggered this report was only surfaced by the R=C2=B3
change, but it is not really directly affected by it. The real problem
is that the R=C2=B3 change made it possible to skip calling the
=C2=ABdebian/rules build=C2=BB targets, where the affected package was alr=

eady

Yes, I know. I=E2=80=99m 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.)

Policy buggy, but the breakage was not visible. If the R=C2=B3 default
would get reverted, but the change to call
=C2=ABfakeroot debian/rules binary-arch=C2=BB kept, the openjdk-8 package =

would

still misbuild.

I know. Doesn=E2=80=99t change the fact that dpkg=E2=80=99s change breaks p=
ackages.

Would you *please* at least read and consider the alternative
solutions I pointed out above? Thanks.

bye,
//mirabilos
--=20
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too=E2=80=A6 may I quote yo=
u on that?
<igli> sure, tho i doubt anyone will listen ;)

[Bill Allombert]

Post by Guillem Jover
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 ?

Cheers,