Package managers need a network dependency contract

Package managers should expose a machine-readable network dependency contract for every application. “Needs internet” is too blunt for desktop administration: downloading an archive, running an installer script, completing first-launch setup, serving core functionality, checking a license, and fetching updates are materially different dependencies.

Some pieces already exist in isolation. Flatpak metadata can grant runtime network access, and an `extra-data` source can download payloads during installation. Snap exposes network capabilities through interfaces. Debian maintainer scripts can run during installation, upgrades, and removal. But that is not a consistent, cross-format declaration an administrator can compare before deployment.

I’d want fields for required versus optional access, timing, destinations where practical, and whether the application remains usable offline. This would improve policy, troubleshooting, and user consent. Is this a useful contract, or would it become another declaration vendors make inaccurately?

The distinction is valuable, but I would avoid implying that a standardized contract already exists. The research supports several format-specific mechanisms, not a Linux-wide schema. The hard part is making declarations auditable rather than merely descriptive; maintainer scripts in particular make “installation network use” difficult to predict from a catalog entry alone.

I’d make “destinations where practical” much stricter. A package saying “network: required” still leaves administrators unable to build a useful allowlist. Also, a declared permission is not proof of benign behavior. The contract should improve visibility, not be marketed as a security boundary.

This is good product metadata if the wording stays human-readable. Most users do not care which phase makes the request; they care whether the app works on a flight and whether setup will stall behind a proxy. Give admins the detailed schema, but expose a plain-language summary in software centers.

I can already hear six package formats agreeing on five incompatible schemas. Still, “offline after install” would be a genuinely useful field. Start there, validate it against reality, and resist turning every possible network event into a committee taxonomy.

The contract should record uncertainty and conditional behavior, not just yes/no values. Optional cloud sync, update checks, and plugins can change the answer over time. A versioned declaration with evidence from the package format would be more honest than pretending one static flag captures the whole application.