On 2026-02-08 09:25, Simon McVittie wrote:
I see that #1031648 has been reassigned from the ftp.debian.org
pseudo-package to the general pseudo-package, presumably because
ftp.debian.org is now the issue tracker for the recently-created
archive operations team, and the questions I asked in #1031648 are
something for what is now the DFSG team (the other half of what used to
be ftp team responsibilities).
Hi Simon,
The DFSG team has discussed your questions regarding the relationship
between archive components and autopkgtests that require internet
access. Here are our answers to your specific points:
1. Downloading third-party data
From a strict DFSG perspective, we treat them the same, but we
acknowledge that it makes sense to restrict execution of external code
for security reasons. Our mandate is to ensure that the source and
binary packages in the archive are DFSG- and Policy- compliant. If an
autopkgtest needs to download data to verify functionality, it should
simply be marked appropriately. The needs-internet flag is the correct
declaration of intent. It is then up to the infrastructure policy (not
the package maintainer) to decide if that flag is honored.
2 & 3. Downloading third-party executable code
As noted above, we do not differentiate between "data" and "code" for
the purpose of these downloads. While we agree that packages in main
should not download data from the internet during builds, for tests, the
needs-internet restriction is the appropriate mechanism, we currently
see no policy-driven need for a more granular distinction (like
"downloading code" vs "downloading data").
4 & 5. Running third-party executable code
From a strict licensing perspective, we do not differentiate between
data and code downloaded during tests, provided the package does not
redistribute that downloaded content. However, we recognize that
executing external code poses security and reproducibility risks. While
these risks do not violate the DFSG, they may impose risks for operating
the machines that run package builds or execute autopkgtests. We
recommend addressing them with virtualization and sandboxing techniques,
rather than asking the Archive Operations or the DFSG team to identify
such issues manually, which is time-intensive and error-prone.
6. Packages in contrib vs. main
The rules for contrib are indeed different. Since contrib packages (like
game-data-packager) are explicitly for software that requires non-free
components to function, it is entirely acceptable for their autopkgtests
to download or run third-party programs that don't meet DFSG
requirements. However, that doesn't mean different rules for using
autopkgtest restrictions to declare intent. Unlike g-d-p, which targets
installing proprietary and non-free games, flatpak's main purpose is to
sandbox and distribute free software. As such, those autopkgtests can
and should focus on DFSG free software packages, which match flatpak's
typical intended use-case.
Regarding Package Removal and Release Eligibility:
You raised a concern that adding these restrictions might trigger
package removal. The DFSG team prefers not to block such packages from
entering the archive. We advocate for tracking these issues via the Bug
Tracking System (BTS) and resolving them through the standard maintainer
workflow, rather than using immediate rejection or removal.
@Release Team: Simon's concern specifically touches on whether packages
explicitly flagged as downloading/running third-party code in main would
be considered unsuitable for a stable release.
Does the Release Team agree with the DFSG team's approach (tracking
these as bugs rather than blockers)?
The DFSG team believes that test-only external dependencies should not
disqualify a package from main, provided the package functionality works
without them and the downloaded artifacts (like OCI images or flatpak
applications) are not included in the resulting .deb files. This allows
for the case at hand where a test ensures the expected behavior when
interacting with external services such as the flatpack archive or
docker image registries. We recommend the Release Team take a similar
stance and permit such packages in testing and stable releases.
We believe clarifying this will resolve the concern about potential
removals.
Best regards,
-rt (on behalf of the DFSG team)
