XPost: linux.debian.devel.release, linux.debian.devel   
   From: siretart@debian.org   
      
   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)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)