Bug#872587: Document the Protected field
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
Bug#872587: Document the Protected field
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
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
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#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Sat 23 Mar 2024 at 05:08pm +01, Holger Wansing wrote: > While working on adapting the parts/7doc script (from Debian Webmaster > Team's 'cron' repo), I realized that this is not going to work out of the > box: while the concept of the symlinks mentioned above is working fine, > when the debian-policy document is installed on a machine as usual > (means it recides in the same path as in the binary deb package, aka > /usr/share/doc/debian-policy/policy.html), we have the docs for the website > on the debian.org website machine in another path. That is in > /srv/www.debian.org/www/doc/debian-policy/. > > That means the (relative) symlinks will not resolve! > Therefore I think the best solution here is, to change the relative > symlinks into absolute ones, on the debian.org website machine. > > I have worked out the needed changes for cron/parts/7doc to deal with all > this (it works fine here locally). The debian-policy package could stay > unchanged. > I attach the patch here just for reference; will apply it, as soon as > sphinx-rtd-theme-common gets installed on wolkenstein > (working on a bugreport to DSA to get this done). > > Closing #1066967 against sphinx-common/dh_sphinxdoc now. > Thanks python people for your help! Many thanks all for working on this, especially you Holger for this scripting work. So, we're waiting in DSA and then on your script changes, and it'll work again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello,
On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:
> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.
I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files
Hello, On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 4307e89..2fb05cd 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -685,7 +685,7 @@ variables are also available. > > The ``debian/substvars`` file is usually generated and modified > dynamically by ``debian/rules`` targets, in which case it must be > -removed by the ``clean`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > > See :manpage:`deb-substvars(5)` for full details about source variable > substitutions, including the format of ``debian/substvars``. > @@ -725,8 +725,9 @@ building packages to record which files are being > generated. > > It should not exist in a shipped source package, and so it (and any > backup files or temporary files such as ``files.new``) [#]_ should be > -removed by the ``clean`` target. It may also be wise to ensure a fresh > -start by emptying or removing it at the start of the ``binary`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > +It may also be wise to ensure a fresh start by emptying or removing it at the > +start of the ``binary`` target. > > When ``dpkg-gencontrol`` is run for a binary package, it adds an entry > to ``debian/files`` for the ``.deb`` file that will be created when Instead of "It may also be wise ..." can you use one of the sets of magic words from Policy 1.1, please? -- Sean Whitton signature.asc Description: PGP signature
