On Sat, 03 Aug 2024 at 19:16:30 +0200, Guillem Jover wrote:
> I'm not sure the current state is ideal, because we are back to
> packages being able to rely on some stuff on build daemons, that are
> not guaranteed by default for our supported build entry points
This was already true, though: the official buildds all run sbuild
(which runs dpkg-buildpackage, not debian/rules), they're all set up in
whatever way that the Debian sysadmins prefer, they probably all run
as uid 'sbuild', they probably all use the same filesystem or one of
only a few filesystems for the build directory and /tmp (ext4? tmpfs?),
until recently they all ran under schroot, now they all run under either
schroot or unshare, and so on. In many ways that's a good thing: their
job is to build packages, not to validate that the packages are resilient
against unusual configurations.
Of course, if a package works on our infrastructure but FTBFS in a
reasonably typical build environment (like a contributor's laptop, or an
ordinary cloud VM image) then that's certainly inconvenient, and is a
bug that should ideally be reported and fixed. I don't think those bugs
always need to be RC: it depends on how "normal" the build environment
is, and how easy it is to work around the problem by building differently.
I don't think it should be a goal to make all of our packages build
successfully in "unreasonable" build environments (whatever we choose to
make that mean). For instance, I suspect that a significant proportion
of the archive will FTBFS if you try to build them on NTFS or SMB/CIFS,
and I'm not convinced that's even a bug: we can and should use a more
suitable filesystem instead.
smcv
