Bug#983304: please document "Protected" field
On Mon, Feb 22, 2021 at 09:23:00AM +0100, Tomas Pospisek wrote:
> Source: debian-policy
> Version: 4.5.1.0
> Severity: wishlist
>
> In Julian Andres Klode's blog I've [1] glimpsed:
>
> > New features
> > [...]
> > The Protected field is now supported. It replaces the previous Important
> > field and is like Essential, but only for installed packages (some minor
> > more differences maybe in terms of ordering the installs).
>
> So I've tried to find out what the "Protected" field is for. The only
> info about it that I could find is from `man 1 dpkg`:
You can also read the spec [1]
[1] https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField
Let's start declaring what this field is:
Essential packages are automatically installed by apt when they are not,
Protected packages are not, but they're otherwise the same. Well, OK not
entirely, but you can think of them as:
Protected <=> Essential (if installed)
Given that they're not installed automatically, it follows that you need
explicit dependencies on them. And APT also does not immediately configure
them given that all dependencies are actually defined.
Or well, the other way to think about it is that this is a package that
cannot be removed without an extra check.
>
> > Protected packages contain mostly important system boot infrastructure.
> > Removing them might cause the whole system to be unable to boot, so use
> > with caution.
>
> That seems a bit vague and sparse.
>
> Is there maybe more rigid information for what *exactly* the "Protected"
> field should and will be used?
What you use them for is obviously not fixed. What we have so far are:
## Essential for some use cases
The init package uses the old Important: yes to be harder to remove so
you don't end up bricking your system into an unbootable one.
That's the "Essential only for some use cases" use case, because init
obviously should not be Essential because we don't want it in an app
container, but we do want it to be Essential when it's already installed.
The same applies to e2fsprogs, which is also marked like that, because
duh, you do not want to be able to remove e2fsprogs on a real system,
but again you don't want it installed automatically in a container.
## Weird hacks in low-level packages
As another example, we marked libgcc-s1 as Protected, because it Replaces:
libgcc1 but can't Conflict with it, so removing libgcc-s1 would remove
the library entirely, so we had to protect it.
## Local metapackages
The original use case was local system configuration meta packages,
where you define a my-machine-foo meta package, and have it depend on
all packages in the system and mark that as Protected: yes[2]; back then
we used XB-Important: yes (well we still do, you gotta set both for
backwards compatibility with stable atm really). Because you then mark
all other packages auto and you then absolutely do not want to lose your
meta package :D
[2] https://blog.jak-linux.org/2012/01/24/managing-system-package-selections-using-custom-meta-packages/
## De-essentializing Essential packages
Packages that were Essential can be downgraded to Protected and
installed systems won't show any change in behavior (avoiding
regressions), whereas the package will no longer be "essential"
on new systems.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: