Re: Please, minimize your build chroots
Hello,
I've previously discussed this topic with Santiago Vila on a bug report
but sharing my opinion here for the wider audience.
On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote:
> El 27/1/23 a las 22:37, Adrian Bunk escribió:
[...]
> This is not the right time to change policy.
This is the right time to question your interpretation of policy.
Policy is not a religion. Policy has many bugs. Policy is very outdated.
Doing something just because an outdated document says so is worse than
not doing anything in my opinion. You need to understand if what you're
actually doing is correct and then see if policy agrees with you to
justify the severity.
Or as the saying goes: Policy is not a stick to beat people with!
Here's an example you could follow:
https://lists.debian.org/debian-policy/2022/12/msg00023.html
(I don't agree with the suggestion. It was however suggested on the
correct list and since there was no traction to the suggestion it was
not followed up with mass bug filing. Minimal disruption to the project.
Updating the definition/description of the Priority levels would however
be very useful. The description seem very outdated, to the point of
being irrelevant, by now.)
[...]
> 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.
Claiming there's no point to free software when the problem is simply
that you are using an *unsupported* setup?!?! All debootstrap variants
include Priority: required packages. As you can see they do so for a
reason!
The --exclude option of debootstrap works equally well even on
Essential: yes packages. Being able to experiment like this is great!
It is however still just an experiment which does not warrant filing
release-critical bugs against various packages.
> > 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.
[...]
There are alot of packages which does not properly build in an unclean
environment. In practise you need a controlled build environment to
properly build debian archive packages form source (which starts with
deboostrap --variant=buildd ...).
If you think people should be able to build on top of their regular
install with various packages installed and various configurations it
would be much better if you tried to fix the many packages who fails in
this scenario.
If you think every packages should list just about all of the archive in
Build-Conflicts just to not pick up unwanted extra autodetected
dependencies that make the package FTBFS then I think it would be
a good idea to check if there's actually project consensus on that.
If you think that every package must use configure flags to override
autodetection of features, seek project consensus. Discuss it on the
policy list, where they'll probably tell you to first fix the archive
(without filing RC-bugs) and then come back.
If you want to do mass bug filing of release-critical severity you
better make sure there's project consensus on what you're doing and
than you're not just wasting everybodys limited time.
Multiple people have now raised their conserns with your approach.
As I've said before I appreciate the bug reports being filed,
even if it's just for "theoretical correctness", but a proper
severity would be wishlist. If your only motivation for this is
to be allowed to file release-critical bugs, then I think it's
better if you just stop.
Regards,
Andreas Henriksson
Reply to: