Hi!
A couple of packages with "Important: yes" has just hit unstable (mount,
fdisk) -- or rather, _would_ hit unstable had dpkg-gencontrol not silently
ignored this field.

The problem is, this field is currently undocumented and unofficial.

Support in frontends in Stretch looks good enough, thus I believe there's no
reason to avoid using this field in Buster.  I've tested apt, dselect, aptitude,
synaptic, gnome-packagekit, apper -- only nit is messages talking about
"essential", but that's okayish.  There is a frontend that doesn't know this
field, cupt, but with popcon vote 23, the cross-section of people who 1. try
to remove an Important:yes package, 2. use cupt, 3. use Stretch's version
of tools to remove a Buster's package, is expected to be nil.

On the other hand, dpkg does not know the field.  It won't say a word upon
removal, and dpkg-gencontrol silently removes it.  Currently to build such a
package you need a hack like:

override_dh_gencontrol:
        dh_gencontrol
        sed -e '2i Important: yes' -i debian/${PACKAGE}/DEBIAN/control


Thus, some Policy guidance would be nice.  Is it legal to use "Important:
yes" at this moment?


As far as I know, the intended behaviour is to make a package:
* easy to not install
* hard to remove
Ie, it's meant to protect stuff like "init" or "mount" from being removed,
while not wasting space on a buildd chroot or a container.
Current state of the these packages is:
* mount: Important:yes, Depends: path from both systemd and
  sysvinit-core→initscripts
* init: no protection at all
Thus obviously "init" wants this to be set.

Hello Adam,

Thank you for filing this bug.

It wouldn't be up to policy whether it's legal.  We document fields in
policy once they are already in use in the archive.

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.

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

Control: block 872587 by 872589

src:util-linux just added it on two of its binaries (mount and fdisk), thus
the field can be said to be in use.

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

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


Meow!

If he just want to use the field, no change to dpkg is necessary.  dpkg
supports user defined fields since at least 15 years, when d-i started
to rely on them.  See deb-src-control(5) for information.

Bastian

Adam Borowski <kilobyte@angband.pl> writes:
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.)

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

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.

ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (wrar@debian.org) kirjoitti:
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

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.

True so far...
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