Bug#872587: debian-policy: please document "Important: yes"
Adam Borowski
Version: 4.0.1.0
Severity: wishlist
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.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-rc5-debug-00121-gc6b5a5fd577f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
pn doc-base <none>
-- no debconf information
Sean Whitton
Thank you for filing this bug.
On Fri, Aug 18 2017, Adam Borowski wrote:
> On the other hand, dpkg does not know the field. It won't say a word upon
> removal, and dpkg-gencontrol silently removes it.
> yes" at this moment?
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.
--
Sean Whitton
Adam Borowski
On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote:
> On Fri, Aug 18 2017, Adam Borowski wrote:
> > Thus, some Policy guidance would be nice. Is it legal to use "Important:
> > yes" at this moment?
>
> 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.
the field can be said to be in use.
> 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.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄⠀⠀⠀⠀
Bastian Blank
> 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.
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
--
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8
Russ Allbery
Adam Borowski <kilo...@angband.pl> 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.
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) <https://www.eyrie.org/~eagle/>