Hi, Quoting Chris Hofstaedtler (2025-02-22 00:52:59) > > Yes, I fully agree that this is not really an issue for scripts, they > > can be adjusted, but it is more problematic for interactive users, > > either directly or probably through sbuild when adding extra chroots. > > In light of todays discussion about build tarballs, a simpler > solution for ca-certificates struck me: why not raise the Priority: > of ca-certificates to important or higher?
you can do that but it will not fix this problem. Debian Policy says: > If build-time dependencies are specified, it must be possible to build the > package and produce working binaries on a system with only essential and > build-essential packages installed Our buildd chroots used to install much more than that until recently when this changed in debootstrap: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106 The majority of the work was done by Santiago Vila who has been diligent with finding and filing bugs for packages which FTBFS with only Essential and build-essential installed. Packages with Priority:required are no longer installed for Trixie and later. There is a bug for mmdebstrap to do the same: #1091866 Note though that even after this change, 'apt' still gets installed into buildd chroots even though it is neither Essential nor build-essential. This is because sbuild cannot (yet) work with chroots that do not have apt installed in them. > I see two good reasons to do this: > > 1) the (non-)presence of ca-certificates in a build environment > should not depend on the used mirror to create the chroot. It's > (non-)presence can cause other packages to FTBFS or otherwise differ > in their builds. Having it always be present would give us a more > consistent build environment. Not having it present also makes the build environment consistent. So consistency is not an argument *for* installing it. In the long run, I propose to go the other way: lets not have apt inside the chroot. Without apt inside the chroot, there is also no ca-certificates required inside the chroot and the problem is solved as well in a consistent way, no? Thanks to reproduce.d.n we also have continuous CI testing package builds in chroots without apt today. This highlights another problem of installing more than build-essential inside buildd chroots: the .buildinfo files will not store information about packages like apt, fakeroot or ca-certificates and thus, rebuilds on reproduce.d.n will not contain them. > 2) I'd argue an OS install that cannot practically speak TLS to > anything is not very useful. I agree. But this is not an OS install. I'd also argue that an OS install should have an init but we do not install and run systemd inside buildd chroots either. I think in contrast to an OS install, a buildd chroot should be as minimal as possible so that we can find problems involving undeclared build dependencies early. > What do people think? > > Should we approach the ca-certificates maintainers and ftpmasters? I'd rather work towards a future that makes buildd chroots smaller, not large. The current soft-blocker in sbuild for apt-less buildd chroots to happen is schroot. In contrast to the unshare backend, the schroot backend is unable to support running apt from outside the chroot. It's not a hard-blocker because using a lot of special-casing, we can make the unshare backend special and let it do different things. But that's not work I have done yet. Thanks to Jochen the first step in this direction is done though and buildds run the unshare backend. I expect that during Trixie, sbuild will also support apt-less chroots. Thanks! cheers, josch
signature.asc
Description: signature
