In Julian Andres Klode's blog I've [1] glimpsed:

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`:

That seems a bit vague and sparse.

Is there maybe more rigid information for what *exactly* the "Protected"
field should and will be used?

Either way, if there's a new control field, then I think it should get
documented in the `debian-policy`?

Thanks,
*t

[1] https://blog.jak-linux.org/2021/02/18/apt-2.2/

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.
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.

Hi!

I've updated that to point to the RFC thread on debian-devel and to
the file shipped by dpkg (/usr/share/doc/dpkg/protected-field.txt),
which are both better resources. In general once these get implemented
in dpkg, the wiki spec pages have stopped being the core canonical
source of information, and are kept for historical purposes or to
keep information that is out-of-scope for dpkg itself (such as
Debian-specific policy or implementation tracking, etc). But I guess
that should be clearly reflected there or the pages kept in sync. I'll
try to do both, and perhaps incorporate any of the following paragraphs,
that might no be already covered from information in the pre-existing
docs once merged.

Thanks,
Guillem

Hi Tomas,

That is indeed vague. However, `Protected` has already been documented in
testing under deb-controls [0].
I hope this helps.

[0] https://manpages.debian.org/testing/dpkg-dev/deb-control.5.en.html


*--Sergio Moraes*
*Data Management Analyst*

Hi Tomas,

That is indeed vague. However, `Protected` has already been documented in
testing under deb-controls [0].
I hope this helps.

[0] https://manpages.debian.org/testing/dpkg-dev/deb-control.5.en.html


*--Sergio Moraes*
*Data Management Analyst*