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