[ Thanks for fixing the bug in unstable so fast ]
I'm all for fixing bugs in stable that:
* are obviously bugs (rather than a point of debate)
You are the only one debating this, but it should really not be a point of
debate.
Packages with missing build-depends are buggy and always have been. This is both
in Debian Policy which we have already quoted and also in Release Policy for
bullseye,
which is the one that counts here:
Packages must list any packages they require to build beyond those
that are "build-essential" in the appropriate Build-Depends: fields.
Ref: 4.2
https://release.debian.org/bullseye/rc_policy.txt
Release Policy exists as a subset of Policy so that we don't have to
discuss each time about which bugs we want a stable release to *never* have.
If you think required packages are automatically build-essential, feel free
to ask debian-policy for clarification.
[ In fact, I wonder why you bothered to add the missing B-D if you really
believe it
is not a bug. There has not been any change in Debian Policy or Release Policy
regarding
this between bullseye and bookworm. Therefore, this is a bug in bullseye (or
not) the
same way it is a bug in bookworm (or not). ].
BTW: I'm not taking the build-essential package to determine which packages are
build-essential or not, because there is already a definition in Policy, namely,
those packages required to build a "hello world" program in C or C++ (Policy
4.2).
I have still 87 FTBFS bugs to fix in stable. You are of course free to
not help me fixing yours.
Per the Developers Reference, a mass bug filing of many bugs on the same
topic is required to be discussed before filing.
Hmm, I have made a mistake in the wording which has led to a misunderstanding.
I didn't say those 87 FTBFS bugs were of the same type. The ones about missing
build-depends are already filed, and most of them are also unfixed in bookworm,
so I believe they are correctly filed.
The other bugs in bullseye are of very different types. Quite a number of them
were already reported by Lucas Nussbaum and fixed in unstable but not in
bullseye, where they also happen. An example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997580
In cases like that I have to "resurrect" the bug and usually I propose
a debdiff to the maintainer for the bullseye upload, when I can.
This is not fixing a bug retroactively, this is ensuring that packages
in stable build in stable, something that we promised at release time
and are not honoring yet (but we are very close).
There are also quote a number of FTBFS bugs which happen because
they contained a "time bomb":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025096
Again, this is not fixing a package retroactively, it's that the package
had a silly unit test which was destined to fail in the future.
I think it is important to honor the promises we made to the users. We
promised a stable release without FTBFS bugs, and we are almost delivering
it, but not completely.
In the end, it boils down to where do we draw the line. You think having
a reduced number of packages which FTBFS according to Policy is ok. I think
the only acceptable number of FTBFS bugs to have in a stable release is zero,
and I am working towards such goal.
So the only thing I ask is that you do not insist that this is not a bug
when I reopen it for bullseye. Since I will be the one doing the work,
I think I should be allowed to use the BTS to track those bugs.
Thanks.
