Should package managers show what install scripts can do?

I’m comfortable trusting signed distribution repositories, but I’m less comfortable with how little of that trust is visible during installation. Debian packages can include preinst, postinst, prerm, and postrm scripts; RPM has similar scriptlets and triggers. These run as part of privileged package transactions and may configure services, change system files, create users, or execute other commands. Usually the interface reduces that to a progress bar.

My preference is a default “inspect capabilities before install” view: show lifecycle scripts, likely service changes, user or group creation, writes outside package-owned paths, and detectable network access. A transaction preview already tells us what packages will change, but not this level of effect. Optional permission boundaries or sandboxing could add protection, with documented escape hatches.

I know maintainers use scripts because copying files cannot handle every migration or service setup, and sandboxing may break legitimate work. Developers and experienced Linux users: please challenge this with real examples, or suggest a better alternative that preserves convenience without making trust invisible.

The capability report is the interesting part; a generic sandbox is harder. A post-install migration may need to read existing configuration, update a database, create a service account, and reload a daemon. I’d rather see package metadata declare intended effects, then let administrators enforce policy where the declaration is missing or too broad. That gives tooling something actionable without pretending isolation is free.

I’d separate “the package contains executable lifecycle code” from “the tool can accurately predict every effect.” The first is documentable; the second may be undecidable in practice. A useful minimum might be reliably surfaced script presence, declared service/user changes, and a link to inspect the actual scripts, alongside the existing simulation modes.

A warning screen only helps if it explains consequences in ordinary language. “Runs postinst” is technically transparent but not very useful to most people. “Creates a system user and enables a service” is better. I’d make the detail expandable, not force every desktop user through an approval ceremony on routine updates.

If the default becomes “approve every script,” people will automate past it or stop updating. Show the information, provide a serious preview, and reserve hard boundaries for users who actually want them. The progress bar is not the whole problem; making the safe path annoying would be another one.