Hi Julien, thank you for your quick reply!
Quoting Julien Cristau (2023-09-28 17:49:51)
> I guess more than mixing two different things I disagree that that is
> debootstrap's responsibility, and so I disagree that that is a valid bug. In
> my view it's more important for debootstrap to reliably be able to create
> chroots than some sort of philosophical purity about what is included in said
> chroot. Package priorities are how the archive tells debootstrap which
> packages to install, and so since I don't see your (A) as a bug, I'm saying
> if there's a bug it's (B) and belongs with the archive.
I agree that debootstrap's reliability to create chroots is supremely
important. But do you see a bug with my change that makes it unreliable? It
changes what the chroot includes yes, but it does so in a reliable way unless I
missed something?
I also agree that "philosophical purity" is a bad argument but "package
priorities are how the archive tells debootstrap which packages to install" is
also not a practical argument but an argument of "we've always done it this way
and that's why we will continue to do it that way". This sounds to me like
another argument of "philosophical purity" instead of one motivated by
practical considerations.
So I'd like to take a step back. There was a big thread on d-devel about this
topic and arguments have been exchanged about this forth and back. I'd like to
use this email to rephrase the argument I have already made for this change.
> I also think your argument, even if I went along with it, breaks down when
> the apt package gets included, since apt is clearly not build-essential, so
> by that logic we'd go back to the days where builds used the host system's
> apt instead of including it in the chroot.
If my argument was of "philosophical purity" then it would indeed completely
break down with making apt the exception. But I'm trying to fix a practical
problem here and thus I'm fine with leaving apt the exception for now. Whether
or not to use apt from the outside would be another discussion we could have
but I do not think it is very useful to have the discussion today. The
practical side of the matter is, that the default schroot backend of sbuild is
unable to use apt from the outside and unless official buildds switch to the
unshare backend, apt has to be included in the chroot.
What this change is trying to achieve is to make it harder for source packages
to make it into the archive that have build dependencies missing. This is my
main motivation. This is also why having apt inside the chroot is not much of a
problem because I cannot remember having seen a source package in the archive
that needed apt to build but was missing it in its Build-Depends.
Source packages with missing build dependencies make QA work on the archive
harder. Santiago is not the only one who found these bugs, Helmut filed bugs
for missing B-D on tzdata and obviously I ran into the problem myself where I
wanted to build a source package but it failed to build because it did not
declare the B-D it actually needed. The time we spend on stumbling over these
bugs, filing them and waiting for them to be fixed could be spent doing more
useful things. We would not have these bugs if source packages were build on
the official buildds in an environment that didn't have extra packages
installed.
So I propose to change the debootstrap buildd variant to install fewer
packages: to help catch this sort of bugs early. In the best case, already on
the developer's machine when they try to build the package.
As always this is a trade-off. If this change to debootstrap is not made, these
bugs will continue to keep happening and the time of some of us will continue
to be wasted on this issue. What is the other side of the coin? If this change
is made, what would break? Santiago already analyzed the archive to find source
packages that would fail and filed bugs. So we know what would break and we
informed the maintainers. What else would break? Would anything else break
other than the principle that debootstrap historically just must include the
priority:required packages just because it has always done it like that?
I really do not understand why using the Priority field and only the Priority
field is a thing that just must keep being used by debootstrap. Why is it a
problem to use the Essential field instead?
Right now, debootstrap is the odd-one-out in the archive. To my knowledge there
is no other software (other than mmdebstrap which will mirror what debootstrap
does by design) which considers the Priority field when selecting packages that
need to be installed to satisfy the build-dependencies of a source package.
Sbuild for example is fine with working on chroots that just include
essenital+apt but it will only install build-essential and not
Priority:required packages. When asking apt to satisfy build dependencies, it
will install build-essenital but not Priority:required packages. When asking
dpkg-checkbuilddeps, it will check whether build-essenital is installed but it
will not check whether Priority:required packages are installed. When telling
dose3 to check for B-D satisfiability, it will only check for build-essenital
but not for Priority:required packages.
So even if we say that we want to change the definition of what must be
installed for a source package to satisfy its build dependencies (policy bug
#1029831), are you and those in favour for this change prepared to:
1. implement this change in all software that resolves build dependencies and
currently does not consider the Priority field? That would be sbuild, dpkg,
apt, dose3, ...
2. file bugs with patches for all source packages that already do declare a
B-D on a package in the Priority:required set because it's a bug to declare
a B-D on a package in the build-essential set
I argue that changing the definition of what build-essential must contain is a
lot of work. We can do that. This is software and we can change it. But are the
proponents of this change prepared to do that work?
On the other hand there is my proposed change to debootstrap which will make
debootstrap finally do the same thing as the other software in the archive. We
know which source packages would break from this change and we filed bugs about
that.
Which path should we rather take? The one I'm proposing has all patches
submitted. The other not so much unless I'm unaware of it?
I'd like to hear a better argument against the change to debootstrap I proposed
other than "we've always done it this way". Software can be changed and we
submitted patches to make this change happen. Now I'd like to understand why
this change is a bad idea in practical terms. What would break that I missed?
Thanks!
cheers, josch
signature.asc
Description: signature
