Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

[Pirate Praveen <praveen@debian.org>]

On 05/05/2025 4:28 pm, Santiago Vila wrote:
> El 3/5/25 a las 17:41, Pirate Praveen escribió:
> > Package: debian-policy
> > Version: 4.7.2.0
> > Control: block 1104509 by -1
>
> Note: I've just removed the block for the reasons stated by Bill.
>
> > I think it should be changed to,
> >
> >  > Except for packages in the non-free archive with the Autobuild 
> > control field unset or set to no,
> >  > required targets must not require network access, except, via the 
> > loopback interface,
> >  > to services on the build host that have been started by the build.
> >
> > I think enforcing there is no internet access is a better way to 
> > achieve the goal of actually ensuring there is no internet during 
> > build rather than considering packages that can use internet when 
> > available for tests as rc buggy.
>
> I think the goal has never been "ensuring there is no internet during 
> build".
>
> When I'm debugging a package, I usually work in a directory-based chroot
> (created with debootstrap). If I had to drop internet access, I would 
> have
> to use firewall rules or just unplug the cable, which would make other
> tasks requiring internet in my computer not to work at the same time.
>
> I would consider the real goal to be ensuring that the package
> builds the same regardless of network being present or not,
> and also regardless of the way you choose to build the package,
> be it dpkg-buildpackage in a chroot, sbuild with unshare, sbuild
> with schroot, pbuilder, etc. It's a requirement which helps
> reproducibility.

at least in this specific instance, the final package remains the same 
irrespective of whether you have internet access or not. So this does 
not affect reproducibility at all. You just test more functionality if 
internet is present, that is all.

This confusion comes because of treating test target in rules exactly 
same way as build target, when in reality both has different effects on 
final binaries and reproducibility.

> I did not want to be the first to reply to this policy bug,
> but I also agree with the others participants that policy is
> ok as it is, and I would also hope we keep enforcing it
> even in cases like this one where the unshare backend hides
> the network access and makes the package build not to fail.
>
> Thanks.

Attachment: OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature