Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote:
> El 27/1/23 a las 22:37, Adrian Bunk escribió:
> > On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
...
> > 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.
>...
Reality in Debian is that at any time a 3 digit number of maintainers is
(sort-term or long-term or permanently) away/busy/MIA.
A large part of QA work in Debian is fixing bugs in packages maintained
by other people, for me that's > 95% of my uploads.
I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.
> > 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.
Policy tends to be a decade behind reality because it *follows*
existing practices.
If existing practice is that build environments have all
"Priority: required" packages installed, then policy should
be updated to follow reality.
> 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.
People who follow the (incomplete) documentation in our wiki for
creating their own buildd setup will get a reasonable setup where
builds have all "Priority: required" packages installed.
> The end user MUST be able to rebuild the packages. Otherwise our
> free software licenses are meaningless in practice.
In general this is true, but you tend to use this argument when trying
force pretty unimportant things on the whole project.
#932795 was your failed attempt to make the Technical Committee decide
that all build failures on single-core machines are release critical
bugs in the year 2019.
> > 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.
In #932795 there was wide consensus that documentation could be improved
to clarify what a supported/reasonable build environment is.
E.g. the maximum amount of diskspace a package might currently use when
building on amd64 is the undocumented tribal knowledge how much storage
is available on our amd64 buildds.
> > 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.
Your argument is based on treating Policy 4.2 as a holy scripture that
must be followed and never questioned.
Policy 4.2 also says
Source packages should specify which binary packages they require to
be installed or not to be installed in order to build correctly.
We are not following the "not to be installed" part,
which is the can of worms you would be opening.
In the section you are referring to, Policy 4.2 also says
In particular, this means that version clauses should be used
rigorously in build-time relationships so that one cannot produce bad or
inconsistently configured packages when the relationships are properly
satisfied.
Personally I would strongly agree with that, but current practice with
Janitor commits removing older version clauses goes in the opposite
direction.
> > 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.
Please don't spread misinformation about the status of a policy that
starts with
*** NOTE: This document has not yet been updated for bookworm ***
Similar to the point about policy above, this could be amended to match
existing practice by requiring all "Priority: required" packages to be
installed.
> Thanks.
cu
Adrian
Reply to: