Show the permission and dependency diff before I approve an update

Running Linux servers has made me suspicious of the single “Update” button. Before every major self-hosted application upgrade, I want an operator-readable permission and dependency diff: new outbound destinations, telemetry, Linux capabilities, background services, changed volumes or permissions, database migrations, and added or removed third-party dependencies.

A small Nextcloud homelab server is a good example. If an upgrade includes database and app migrations, I should see that clearly and be reminded that a current backup matters—not discover it halfway through a maintenance window. Today, the practical pattern is often approving first and learning about changed behavior afterward.

I realize maintaining accurate manifests would burden small open-source projects, especially when dependencies and container settings move quickly. But even a limited, machine-readable declaration would be better than silence. Should this become a packaging standard, a project best practice, or is it unnecessary bureaucracy?

There is already a partial precedent in Debian metadata: dependencies and package relationships are declared, and maintainer scripts can run during upgrades. The missing piece is presenting the behavioral delta in a way an operator can actually review. I would support a standard schema, but not pretend the schema alone guarantees completeness.

The outbound-connection field is the one I care about most. “Uses the network” is too vague; an administrator needs destinations, purpose, and whether the connection is optional. Telemetry hidden inside a routine upgrade is a trust failure, even if the capability list looks harmless.

I like the idea, but “before every major update” needs a sane definition. If a two-person project has to maintain a perfect manifest across native packages, containers, plugins, and distro variants, the project may just stop shipping. Make the common fields easy and allow “unknown” rather than creating paperwork theater.

A diff should distinguish declared behavior from observed behavior. A project can declare that it needs network access, but that does not tell me which hostnames a plugin will contact at runtime. I would still want the manifest, provided the UI labels its confidence and source.

Database migrations deserve a separate approval gate, not a footnote in release notes. They can be irreversible from the operator’s perspective, while a dependency update is usually a different risk category. One combined diff may be convenient but too easy to skim past.

This sounds like packaging standards growing a conscience, which is probably overdue. But standards tend to become mandatory fields nobody reads. Give me a plain-text diff in the package manager and a reliable failure when a project claims less than it does.

I’m not convinced “telemetry” belongs in the same approval screen as a new database migration. The former is a policy and trust question; the latter can take the service offline. Separate risk classes would make the review shorter and more useful instead of turning it into another wall of green checkmarks.