Re: Please, minimize your build chroots
El 27/1/23 a las 22:37, Adrian Bunk escribió:
On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
Greetings.
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).
This is of course not fun for the maintainers, but it's also not fun
for people doing QA, because those bugs could be caught earlier in the
chain, but they are not. This is extra work for everybody.
Speaking as someone who is doing a lot of QA work, for *build*
environments I would rather expand build-essential instead of doing
extra QA work that consists of manually adding build dependencies for
packages that are in practice anyway installed in all build
environments.
This is not the right time to change policy.
There are important real-world usecases where reducing the essential set
brings benefits, but for *build* essential there are not really benefits
that are worth the extra work.
That's your opinion, and I believe you are wrong. I explained the benefits
in the aborted debian-policy proposal to clarify build-essential.
I am right now looking at #1027382, and the first question is how I can
make apt remove e2fsprogs so that I can reproduce the problem - it feels
like a real waste of my QA work to "fix" something that is incredibly
hard to break.
You don't have to fix #1027382. The maintainer has.
Also, you don't have to use apt. You can use dpkg --purge inside the chroot.
Easy enough. Or you can fix the infamous debootstrap bug which is the
root of all this.
It has been practice for many years that FTBFS that do not happen on the
buildds are usually not release critical bugs, and I would appreciate if
this is followed by everyone.
Well, that's also wrong, because having the build-dependencies correct has been
in the list of RC bugs for many years as well. See below.
I would appreciate if we all followed Policy 4.2, which says packages MUST build
when the build-dependencies are installed.
In general, disputing the severity because it does not happen in the buildds
misses completely the point of what should be the goal, namely, a distribution
which may be rebuilt by everybody following documented procedures, not
a distribution which may only be rebuilt in our buildds.
The end user MUST be able to rebuild the packages. Otherwise our
free software licenses are meaningless in practice.
It is not helpful if people try to force the few people who are doing
QA work to spend their scarce QA time on fixing bugs that only happen
when building on single-core machines or in non-UTF-8 locales or without
packages that are in practice installed everywhere, by making such
issues that are not a problem on our buildds release critical bugs.
That's the wrong approach. If the end user wants to make a modification,
they can't use our buildd network.
It also opens a gigantic can of worms, since there is the even bigger
opposite problem that many packages FTBFS or are built differently
when built in an environment that differs from our buildd setup.
Adding Build-Conflicts for all such cases is not feasible in practice.
This is a straw-man. I'm not opening any can of worms.
If people want to support building without tzdata [...]> but none of these are critical for our releases since
none of these impact how packages are built for bookworm on our buildds.
There is a list of RC issues. It's called Release Policy, and it says this:
Packages must list any packages they require to build beyond those
that are "build-essential" in the appropriate Build-Depends: fields.
Ref: 4.2
Source: https://release.debian.org/testing/rc_policy.txt
Release Policy exists as a canonical list of what should be RC and
what not, and it's intended to avoid stupid discussions like this one.
So, according to Release Policy, your claim that a missing build-depends
is not release critical is false by definition.
Please do not spread misinformation about what is RC and what is not
when we already have a canonical list for RC issues.
Thanks.
Reply to: