Should package managers show a capability receipt?

As a Linux desktop user, I like knowing that I own the system rather than merely borrowing an interface. Package managers already show technically accurate dependency and transaction details—APT can simulate installs, for example—but the output is still opaque to many people. I’d like a plain-language “capability receipt” before installation: dependencies, services that may be enabled, network access, filesystem locations, background tasks, and what removal will actually delete.

This is harder than a file list. Maintainer scripts can perform procedural actions, and behavior depends on distro policy, service configuration, and runtime choices. “Network access” should also distinguish downloading during installation from what the installed program can do later. Flatpak’s permission metadata points in this direction, but making every DEB/RPM package describe itself perfectly could burden maintainers and complicate packaging. Should previews be mandatory, distro-specific, or left to third-party tools? Share projects, objections, or packages that surprised you.

The receipt is useful only if it separates declared effects from observed effects. A package can list files and invoke maintainer scripts, but predicting every runtime subprocess or network destination is a different problem. I’d support a clear transaction preview, with uncertainty labels rather than a false promise of completeness.

APT simulation is a good baseline because it shows planned unpack, configuration, and removal actions. The missing layer is translation: “install these 14 packages” is less meaningful than “add a service, place files here, and retain this data after removal.” I’d favor a shared vocabulary before mandating a universal format.

I’d be careful with the word “permission.” A package manager can report declared metadata, but that does not automatically constrain a traditional application. Flatpak can expose network, device, D-Bus, and filesystem permissions; arbitrary packages may still have broad system access. Visibility is valuable, but it is not a sandbox.

Plain language matters here because ownership is partly an interface question. A wall of dependency names technically informs me while still making the meaningful consequences hard to see. I’d put the short receipt first and keep the exact transaction, scripts, and file lists one click away for people who want audit detail.

Mandatory sounds like a good way to produce a checkbox nobody reads. Make the data available in a consistent machine-readable form, then let desktops choose how much to display. Also, removal should say “package files” versus “user data”; those are routinely treated as the same thing when they are not.

The uncomfortable case is distro policy. The same package can behave differently depending on service defaults, init setup, configuration, and update state. A distro-specific receipt may be more honest than a universal promise, while third-party tools can add inspection without blocking maintainers who cannot model every edge case.