Bug#872587: Document the Protected field

[Simon McVittie]

On Wed, 27 Mar 2024 at 14:43:40 +0200, Martin-Éric Racine wrote:
> ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (w...@debian.org) 
> kirjoitti:
> > "Essential: yes" are always installed. Tools and dependencies assume they
> > are installed.  Bootstrapping tools install them implicitly. Package
> > management tools refuse to remove them.
> >
> > "Protected: yes" are nothing like that. Package management tools refuse to
> > remove them and that's all.

Another way to look at this is that if a Protected package is already
installed, then package management behaves as though it's Essential,
but if a Protected package is merely available from a configured apt
source, then nothing special happens.

> Protected: yes|no
> This field prevents a package from getting auto-removed by dpkg
> without using one of the force options.

True so far...

> It is intended for custom
> local packages not meant for upload to the Debian repository.

... but this isn't the whole story. Protected: yes is also appropriate
for non-local packages that are required for system boot, or for package
management. The design principle is that if it would be hard to recover
from removing a package once it has been installed, then it's Protected.

An example of Protected: yes on boot packages is that the init metapackage
is Protected: yes, to make sure you don't accidentally remove the init
system and make the system unbootable (which is hard to recover from
because before you can install a new init system, you need to be able to
boot). It might also make sense for bootloaders like grub to be Protected:
yes, although currently they are not.

An example of Protected: yes on package management packages is that it
would be appropriate to put Protected: yes on apt (although in fact apt
is hard-coded to behave that way even without Protected: yes), to avoid
accidentally getting into a situation where you have removed apt
(which is hard to recover from because now there's no package manager,
and no easy-to-validate trust chain to check that a manually-downloaded
apt_*.deb is authentic).

smcv

Bug#872587: Document the Protected field

[Martin-Éric Racine]

ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (w...@debian.org) kirjoitti:
>
> On Wed, Mar 27, 2024 at 01:29:50PM +0200, Martin-Éric Racine wrote:
> > > The documentation from deb-control(5) is:
> > >
> > > Protected: yes|no
> > > This field is usually only needed when the answer is yes.  It denotes
> > > a package that is required mostly for proper booting of the system or
> > > used for custom system-local meta-packages.  dpkg(1) or any other
> > > installation tool will not allow a Protected package to be removed (at
> > > least not without using one of the force options).
> > >
> > > It's probably also worth noting the parenthetical comment in the
> > > documentation of Essential:
> > >
> > > Essential: yes|no
> > > This field is usually only needed when the answer is yes.  It denotes
> > > a package that is required for the packaging system, for proper
> > > operation of the system in general or during boot (although the latter
> > > should be converted to Protected field instead).  dpkg(1) or any other
> > > installation tool will not allow an Essential package to be removed
> > > (at least not without using one of the force options).
> >
> > I'm still not sure that I inderstand the difference between those two.
> > They seem to accomplish the same thing. Did I miss something?
> Per my understanding which may be flawed:
>
> "Essential: yes" are always installed. Tools and dependencies assume they
> are installed.  Bootstrapping tools install them implicitly. Package
> management tools refuse to remove them.
>
> "Protected: yes" are nothing like that. Package management tools refuse to
> remove them and that's all.

Thanks. This sounds much clearer already. In that case, the above
deb-control(5) needs a much better phrasing. Something like:

Protected: yes|no
This field prevents a package from getting auto-removed by dpkg
without using one of the force options. It is intended for custom
local packages not meant for upload to the Debian repository.

Essential: yes|no
This field prevents a package from getting auto-removed by dpkg
without using one of the force options. It also makes debootstrap and
other similar tools force-install them. Maintainers must request
approval from the debian-devel mailing list before uploading any
package with the Essential field set to the Debian repository. See
Essential packages (Section 3.8) in the Debian Policy Manual for
details.

Martin-Éric

Bug#872587: Document the Protected field

[Andrey Rakhmatullin]

On Wed, Mar 27, 2024 at 01:29:50PM +0200, Martin-Éric Racine wrote:
> > The documentation from deb-control(5) is:
> >
> > Protected: yes|no
> > This field is usually only needed when the answer is yes.  It denotes
> > a package that is required mostly for proper booting of the system or
> > used for custom system-local meta-packages.  dpkg(1) or any other
> > installation tool will not allow a Protected package to be removed (at
> > least not without using one of the force options).
> >
> > It's probably also worth noting the parenthetical comment in the
> > documentation of Essential:
> >
> > Essential: yes|no
> > This field is usually only needed when the answer is yes.  It denotes
> > a package that is required for the packaging system, for proper
> > operation of the system in general or during boot (although the latter
> > should be converted to Protected field instead).  dpkg(1) or any other
> > installation tool will not allow an Essential package to be removed
> > (at least not without using one of the force options).
> 
> I'm still not sure that I inderstand the difference between those two.
> They seem to accomplish the same thing. Did I miss something?
Per my understanding which may be flawed: 

"Essential: yes" are always installed. Tools and dependencies assume they
are installed.  Bootstrapping tools install them implicitly. Package
management tools refuse to remove them.

"Protected: yes" are nothing like that. Package management tools refuse to
remove them and that's all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#872587: Document the Protected field

[Martin-Éric Racine]

On Mon, 11 Sep 2023 21:27:09 -0700 Russ Allbery  wrote:
> Control: retitle -1 Document the Protected field
>
> Adam Borowski  writes:
> > On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote:
>
> >> Do you have any idea how long we can expect to wait until dpkg supports
> >> the field?  I would suggest that we wait until dpkg has defined
> >> behaviour for the field, as it will make documenting it much easier.
> >> It will also allow us to be more confident that there is no serious
> >> disagreement about the purpose of the field.
>
> > Right, let's have dpkg maintainers tell us what they think.
>
> >> I couldn't find a bug against dpkg, but if there is one, it should
> >> probably be set to block this bug.
>
> > 872587 < 872589, I filed the Policy one first.  Block added.
>
> Per the resolution of #872589, this was implemented as the Protected field
> instead.  Retitling the bug accordingly.
>
> The documentation from deb-control(5) is:
>
> Protected: yes|no
> This field is usually only needed when the answer is yes.  It denotes
> a package that is required mostly for proper booting of the system or
> used for custom system-local meta-packages.  dpkg(1) or any other
> installation tool will not allow a Protected package to be removed (at
> least not without using one of the force options).
>
> It's probably also worth noting the parenthetical comment in the
> documentation of Essential:
>
> Essential: yes|no
> This field is usually only needed when the answer is yes.  It denotes
> a package that is required for the packaging system, for proper
> operation of the system in general or during boot (although the latter
> should be converted to Protected field instead).  dpkg(1) or any other
> installation tool will not allow an Essential package to be removed
> (at least not without using one of the force options).

I'm still not sure that I inderstand the difference between those two.
They seem to accomplish the same thing. Did I miss something?

It should also be noted that, as of version 2.117.0, Lintian still
gives a warning whenever a binary target has the Protected field set.

Martin-Éric

Processed: Re: Bug#872587: Document the Protected field

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 Document the Protected field
Bug #872587 [debian-policy] debian-policy: please document "Important: yes"
Changed Bug title to 'Document the Protected field' from 'debian-policy: please 
document "Important: yes"'.

-- 
872587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872587
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#872587: Document the Protected field

[Russ Allbery]

Control: retitle -1 Document the Protected field

Adam Borowski  writes:
> On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote:

>> Do you have any idea how long we can expect to wait until dpkg supports
>> the field?  I would suggest that we wait until dpkg has defined
>> behaviour for the field, as it will make documenting it much easier.
>> It will also allow us to be more confident that there is no serious
>> disagreement about the purpose of the field.

> Right, let's have dpkg maintainers tell us what they think.

>> I couldn't find a bug against dpkg, but if there is one, it should
>> probably be set to block this bug.

> 872587 < 872589, I filed the Policy one first.  Block added.

Per the resolution of #872589, this was implemented as the Protected field
instead.  Retitling the bug accordingly.

The documentation from deb-control(5) is:

Protected: yes|no
This field is usually only needed when the answer is yes.  It denotes
a package that is required mostly for proper booting of the system or
used for custom system-local meta-packages.  dpkg(1) or any other
installation tool will not allow a Protected package to be removed (at
least not without using one of the force options).

It's probably also worth noting the parenthetical comment in the
documentation of Essential:

Essential: yes|no
This field is usually only needed when the answer is yes.  It denotes
a package that is required for the packaging system, for proper
operation of the system in general or during boot (although the latter
should be converted to Protected field instead).  dpkg(1) or any other
installation tool will not allow an Essential package to be removed
(at least not without using one of the force options).

(And while we're there, we don't document the Build-Essential field
either.)

-- 
Russ Allbery (r...@debian.org)