Package: dgit-infrastruture
Version: 15.5
Debian tag2upload service writes ("[tag2upload 3621] irrecoverable yasi-daemon
0.0.0.2-1~exp2"):
> builder$ dgnnnit --version
> dgit version 1n5.4
...
> dpkg-source: error: can't build with source format '3.0 (native)': native
> package version may not have a revision
This is #737634 [1].
We are experiencing this problem in tag2upload because tag2upload [2]
is using dpkg from trixie, which is still afflicted by that bug:
the fix is only in forky.
Options that are technically possible are:
A. Cross-port the patch that Ubuntu are using from Ubuntu to trixie's
dpkg and send it to trixie-proposed-updates. This is, from a
technical and risk/release management point of view, very good. It
fixes the problem and has very low technical risk. It would mean
that people who get "3.0 (native)" packages from forky and try to
unpack and repack them on trixie, won't get spurious bugs, which is
highly desirable.
B. Have tag2upload use dpkg from forky. This is not great, because
dpkg does seem to break things occasionally. (In another context,
see for example #1130119.) But src:dgit does have a pretty
comprehensive test suite which has caught dpkg regressions before
and we could hope that it will do so again, and soup it up if it
doesn't. We could go back to dpkg from stable when forky is
released.
C. Backport dpkg and use dpkg from backports. The dpkg maintainer
pointed out to me that dpkg is not usually backported, for very
good reasons. I think we can rule out this option.
D. Defer all use of "3.0 (native)" for packages with a revision
until after forky has been released. Use 1.0 native instead.
This would be very unfortunate. I don't think we (the git
transition team) should accept this option.
(A) is obviously best from a technical point of view, but it presents
severe political difficulties. However, if we don't do (D), either
(A) or (C) becomes very desirable for downstreams.
I therefore propose:
1. We implement (B) immediately.
2. After (B) is deployed and shown to be working, we go to the
Technical Committee (for the third time!) to ask them to
authorise (A).
Ian.
[1]
This saga makes me cross every time I encounter it again.
In 20213, dpkg-source was changed (#737634) to refuse to build
"3.0 (native)" format packages with a revision in the version number
(#700177). It had accepted these since at least 2005, see eg #314352.
An extensive discussion followed but Guilem didn't participate.
Ubuntu patched their version of dpkg to relax this restriction and it
has been working fine there ever since.
In the intervening years the Technical Committee became considerably
more functional and started actually overruling maintainers
occasionally.
In 2022 on my petition the Technical Committee ruled (#1007717) that
> 1. It is not a bug of any severity for a package with a non-native
> version number to use a native source package format.
...
> 3. We suggest that the wontfix tag on #737634 be reconsidered.
but dpkg's behaviour did not change, because of the TC's feeble
wording.
In May 2025 I referred this to a differently constituted TC again. In
#1106402 it appeared very likely that the TC would overrulke the dpkg
maintainer. This was during the trixie freeze.
There was a very simple diff - Ubuntu's - which could have met the
description of "Only small, targeted fixes". However, the dpkg
maintainer produced FUD and the release team were sceptical.
Instead, the TC were apparently satisfied by the dpkg maintainer
making a much larger change to the dev branch, targeting forky.
That was committed in June 2025.
Following that I kept getting occasional requests from the TC to me to
say "are you satisfied and can we close this bug", in response to
which I kept pointing out that the fix still hadn't been uploaded.
It was eventually uploaded in December 2025. Due to other regressions
in the same upload (which contained a *lot* of other stuff) it finally
migrated to forky in January 2026.
[2] Specifically, the builder container image.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
