Bug#983304: please document "Protected" field
Hi!
On Mon, 2021-02-22 at 11:30:08 +0100, Julian Andres Klode wrote:
> 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
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.
> 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.
Thanks,
Guillem
Reply to: