Your message dated Sun, 07 Apr 2024 05:34:03 +0000 with message-id <e1rtlaj-005xgc...@fasolo.debian.org> and subject line Bug#1035733: fixed in debian-policy 4.7.0.0 has caused the Debian Bug report #1035733, regarding debian -policy: packages must not use dpkg-divert to override default systemd configuraton files to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1035733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035733 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: debian-policy X-Debbugs-CC: bi...@debian.org pkg-systemd-maintain...@lists.alioth.debian.org It has come to my attention that there is one package in Debian using dpkg-divert to mask a systemd configuration file (an udev rule). Speaking as one of the maintainers, both upstream and downstream, I find this greatly undesirable for several reasons that I will outline later. Hence I would like to propose explicitly mentioning that dpkg- divert must not be used for systemd configuration files (units, rules, etc), and instead the supported workflow (drop-ins, masking, etc) must be used, both by packages and administrators. This is already standard practice, and again there is only one instance that needs correcting as far as I understand, and I have already provided a bug and a MR for that [1][2]. So the impact of this policy change should be minimal, and it's mostly to ensure more such instances are accidentally added in the future. I have a draft policy update, that adds a paragraph to the dpkg-divert section of the policy. It is attached here, and also available on Salsa on my fork [3]. The full reasoning below is what I provided on the MR for the one existing instance, and I'll copy it mostly unchanged as I hope it's exhaustive enough. It uses the one existing instance I found as concrete example. This is not intended to single out the maintainer or assign blame, but merely to illustrate the point with a concrete and real use case. Quoting from the MR: One of the main goals behind the systemd (and its udev component) project is to unify how the low-level userspace components of a Linux distro work, so that the exact same mechanisms, patterns, behaviours and interfaces apply to a multitude of use cases, implementations and tools. A core part of this is the configuration system. The configuration system supports a complex schema of main contents, overrides, drop-ins, masking and aliasing. This system is used and understood by all systemd components, across all Linux distributions, with the same interface, look and feel, so that users can feel at home and know how to work the system regardless of the vendor, and so that programs can rely on a stable and common interface that doesn't have to be endlessly customized depending on which vendor or distribution it is used by. The concept of 'masking' a configuration is well understood, ubiquitous and fully supported by all the tooling, including in input _and_ output, and logging, and so on. By using the supported mechanism for masking we ensure that there are no surprises for users, coders and vendors. When an unsupported masking mechanism is used, as in this case, the fact that the original item is masked is completely hidden to the systemd components, and thus to the interface provided to the user. This causes at best confusion and misunderstanding, and at worst bugs that will inevitably fall on the systemd maintainers, causing increased workload for an already over stretched team. A simple and obvious example of what I am referring to is already included in the git commit for this change. Consider what happens when udev parses the vanilla configuration (ie: without amazon-ec2-utils installed): $ udevadm test /dev/cdrom 2>&1 | grep 60-cdrom_id Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules The user/system/log is clearly notified that the file is parsed, there are no errors, and thus is used. Now consider what happens when the current version of amazon-ec2-utils is installed: $ udevadm test /dev/cdrom 2>&1 | grep 60-cdrom_id Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules It looks exactly the same. But something extremely different is actually happening, in fact the opposite! The file is empty, so the vanilla rule is effectively masked, but nothing and nobody is notified of this very important fact when udev is running. One would have to query dpkg-divert to figure this out, but this is something that even someone like me, who can reasonably consider myself a proficient Debian user, would not think of looking at. Now finally consider what happens if amazon-ec2-utils with my proposed change is installed: $ udevadm test /dev/cdrom 2>&1 | grep 60-cdrom_id Skipping overridden file '/lib/udev/rules.d/60-cdrom_id.rules'. Skipping empty file: /etc/udev/rules.d/60-cdrom_id.rules There is an extremely clear, obvious and expected indication that the original rule is ignored because it is overridden, _and_ that the override is empty, as it's a masking operation. Now udev is a bit older than the other components, so "masking" is not named explicitly as it would be for example by systemctl, but it is the same operation and the same result and the same interface. Something I should probably improve a bit upstream, I will take a note of this. Here's another example with systemctl and units. I have masked systemd- homed.service via `systemctl mask` and this is what the interface shows me when I check the status: $ systemctl status -l --no-pager systemd-homed.service ○ systemd-homed.service Loaded: masked (Reason: Unit systemd-homed.service is masked.) Active: inactive (dead) since Sun 2023-05-07 18:59:51 BST; 7s ago <snip> Message is clear and unambiguous, I masked the unit so it will not run. Here's what happens if I unmask it and instead dpkg-divert the vanilla unit with a /bin/true no-op: # systemctl status systemd-homed.service ○ systemd-homed.service Loaded: loaded (/usr/lib/systemd/system/systemd-homed.service; enabled; preset: enabled) Active: inactive (dead) since Sun 2023-05-07 18:59:51 BST; 4min 49s ago <snip> From the output, it's all good. The vanilla unit is enabled and should run and provide its services on the next boot or when I next start it, except it's not - it's been dpkg-diverted to a no-op, but there's no indication there. This is poor UI, poor experience, poor integration. And it's just the most basic, obvious example of what can go wrong: I cannot guarantee that there won't be more, higher severity issues, but I can certainly state that I will provide no support when they inevitably surface, as this is not a supported mechanism. The supported mechanism for masking, for both local admins and packages, is masking via symlinks to /dev/null in /etc. And again I must stress that packages configure things in /etc too, not only administrators! This is fully expected and supported. For example, deb- systemd-helper from init-system-helpers (https://sources.debian.org/src/init-system-helpers/1.65.2/script/deb-systemd-helper/ ) is used in Debian/Ubuntu and derivatives to enable/disable/mask/alias units, and these changes are performed from auto generated (by debhelper https://sources.debian.org/src/debhelper/13.11.4/dh_installsystemd/) maintainer script snippets not too dissimilar to what I have in this MR. And this does not only apply to files that the packages own! It also applies cross-packages. For example, by installing the 'dbus- broker' package, an alias to dbus.service that effectively masks and takes over dbus.service from the dbus-daemon package is installed in /etc by the maintainer script: $ ls -l /etc/systemd/system/dbus.service lrwxrwxrwx 1 root root 43 May 6 17:45 /etc/systemd/system/dbus.service -> /usr/lib/systemd/system/dbus-broker.service From `/var/lib/dpkg/info/dbus-broker.postinst`: # Automatically added by dh_installsystemd/13.11.4 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then # The following line should be removed in trixie or trixie+1 deb-systemd-helper unmask 'dbus-broker.service' >/dev/null || true # was-enabled defaults to true, so new installations run enable. if deb-systemd-helper --quiet was-enabled 'dbus-broker.service'; then # Enables the unit on first installation, creates new # symlinks on upgrades if the unit file has changed. deb-systemd-helper enable 'dbus-broker.service' >/dev/null || true else # Update the statefile to add new symlinks (if any), which need to be # cleaned up on purge. Also remove old symlinks. deb-systemd-helper update-state 'dbus-broker.service' >/dev/null || true fi fi # End automatically added section This is supported, intended and expected, as it's the correct mechanism to do aliasing and overriding. No local user action is performed, everything is done by the package being installed. In effect, the user action IS installing the package. Ensuring Debian packages use a supported, intended and expected mechanism to manage and configure systemd files is fundamental for the ability of the systemd downstream maintainers team to be able to fully and effectively support Debian and its users. Deviating from the expected path causes additional workload, unexpected incidents and general discomfort for an already over-worked and small team, while providing no tangible benefit, as the net result is the same. [0] https://salsa.debian.org/cloud-team/amazon-ec2-utils/-/merge_requests/2 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035667 [3] https://salsa.debian.org/bluca/policy/-/tree/systemd_overrides -- Kind regards, Luca BoccassiFrom 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Luca Boccassi <bl...@debian.org> Date: Mon, 8 May 2023 03:21:14 +0100 Subject: [PATCH] Forbid using dpkg-divert for systemd configuration files The supported mechanism for augmenting, changing, overriding and disabling systemd configuration files is natively supported and fully integrated in Debian, via drop-ins, hierarchical overrides, and masking. dpkg-divert is not integrated in systemd tools so its use is completely hidden in logs and status interfaces, and it is specific to Debian and thus diverges from what users expect as implemented by all other distros, going against one of the core goals of the systemd project which is to provide a uniform interface regardless of distro vendor or flavour. --- policy/ap-pkg-diversions.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst index fe360d1..00bbc04 100644 --- a/policy/ap-pkg-diversions.rst +++ b/policy/ap-pkg-diversions.rst @@ -81,3 +81,23 @@ when the file does not exist. Do not attempt to divert a conffile, as ``dpkg`` does not handle it well. +Do not divert systemd configuration files - `units, +<https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_ +`udev rules, +<https://www.freedesktop.org/software/systemd/man/udev.html#Rules%20Files>`_ +`tmpfiles.d, +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#Configuration%20Directories%20and%20Precedence>`_ +`sysusers +<https://www.freedesktop.org/software/systemd/man/sysusers.d.html#Configuration%20Directories%20and%20Precedence>`_ +and other such files, including those specific to systemd daemons (e.g.: +`/etc/systemd/system.conf). +<https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>`_ +systemd and all its components natively support overriding configuration files +as they are shipped by the distribution, for both local administrator changes +and for changes applied from other packages, as specified in the documentation. +You must utilize those mechanisms to override, enhance or mask systemd +configuration files, as defined in the apposite systemd documentation. +Following upstream's best practices and supported workflows ensures that user +experience is streamlined and without surprises. It also simplifies support and +maintenance. +signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---Source: debian-policy Source-Version: 4.7.0.0 Done: Sean Whitton <spwhit...@spwhitton.name> We believe that the bug you reported is fixed in the latest version of debian-policy, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1035...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sean Whitton <spwhit...@spwhitton.name> (supplier of updated debian-policy package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sun, 07 Apr 2024 13:08:55 +0800 Source: debian-policy Architecture: source Version: 4.7.0.0 Distribution: unstable Urgency: medium Maintainer: Debian Policy Editors <debian-policy@lists.debian.org> Changed-By: Sean Whitton <spwhit...@spwhitton.name> Closes: 963524 968226 970234 994008 1029211 1035733 1039102 1068192 Changes: debian-policy (4.7.0.0) unstable; urgency=medium . [ Sean Whitton ] * Policy: Prefer native overriding mechanisms to diversions & alternatives Wording: Luca Boccassi <bl...@debian.org> Seconded: Sean Whitton <spwhit...@spwhitton.name> Seconded: Russ Allbery <r...@debian.org> Seconded: Holger Levsen <hol...@layer-acht.org> Closes: #1035733 * Policy: Improve alternative build dependency discussion Wording: Russ Allbery <r...@debian.org> Seconded: Wouter Verhelst <wou...@debian.org> Seconded: Sean Whitton <spwhit...@spwhitton.name> Closes: #968226 * Policy: No network access for required targets for contrib & non-free Wording: Aurelien Jarno <aure...@debian.org> Seconded: Sam Hartman <hartm...@debian.org> Seconded: Tobias Frost <t...@debian.org> Seconded: Holger Levsen <hol...@layer-acht.org> Closes: #1068192 . [ Russ Allbery ] * Policy: Add mention of the new non-free-firmware archive area Wording: Gunnar Wolf <gw...@gwolf.org> Seconded: Holger Levsen <hol...@layer-acht.org> Seconded: Russ Allbery <r...@debian.org> Closes: #1029211 * Policy: Source packages in main may build binary packages in contrib Wording: Simon McVittie <s...@debian.org> Seconded: Holger Levsen <hol...@layer-acht.org> Seconded: Russ Allbery <r...@debian.org> Closes: #994008 * Policy: Allow hard links in source packages Wording: Russ Allbery <r...@debian.org> Seconded: Helmut Grohne <hel...@subdivi.de> Seconded: Guillem Jover <guil...@debian.org> Closes: #970234 * Policy: Binary and Description fields may be absent in .changes Wording: Russ Allbery <r...@debian.org> Seconded: Sam Hartman <hartm...@debian.org> Seconded: Guillem Jover <guil...@debian.org> Closes: #963524 * Policy: systemd units are required to start and stop system services Wording: Luca Boccassi <bl...@debian.org> Wording: Russ Allbery <r...@debian.org> Seconded: Luca Boccassi <bl...@debian.org> Seconded: Sam Hartman <hartm...@debian.org> Closes: #1039102 Checksums-Sha1: cceb560f2e75c99e38aade67c89ee61e09e7a3e5 2136 debian-policy_4.7.0.0.dsc fb76348525ee83aa8b75eee50d1d0d166997ca5d 560352 debian-policy_4.7.0.0.tar.xz Checksums-Sha256: 57cf3ee833405240396b40cc9ee65568c09cb9bd421c8cfdec1ff03cba287319 2136 debian-policy_4.7.0.0.dsc cc53cfec06db76e6a26dd61b6f4f8015e95637fc67d5715c54487507ee113a40 560352 debian-policy_4.7.0.0.tar.xz Files: ab2b8b895ec9092a064a72cf0665c47a 2136 doc optional debian-policy_4.7.0.0.dsc 2f658f4169866f3db703cf78e96dcb9a 560352 doc optional debian-policy_4.7.0.0.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmYSLcMACgkQaVt65L8G YkCyJg//cXSHspKUQgje2QUDvo+FMIEWjg8sYUUHhdnq6xLHlc8fxcID1V1kH7F0 bGSzmfJyBTbALWDTmrr9O5dIkSy7Fe4D+qY95r0wuWJ0F2GNyL4sYyBUMwdtevgj ZoDoO69R/Z9ae54ouFMNg7q8gioWM2HZyvz7Fi8i2fTOfjl1RkAaVgP5IzOSL7OY AdOPuLRA4OxzwmdoIyuDfzE3ypXA+EThMIRzmsQfeHS2+9WTaqpXCF9DxoSRhrl2 F3K+KATvfd78aWlN3aF3dFbDck4oz2wx+3CH0Q0kFZhlQPs/oXiiRA5Sz1d3ILfK fX8k0FAATlPWxEEXTsrYPjPQ0Pp6sJKr10K3iZr4RHBOdH9y+XTNavEw+5M5V2Ga x0ht/HeZwgrGyxJeBJ+SOgZ1WE02UbJVBwPtaR2IVlLJNJH7p5Sjo3JXfwUKcVFG o+8VcACg+wilO40lynWSVm7/QBFt9BzjOTXiVO7FJsCrYv0sJQFZwlQOdI5oAwEs FQvxBJKnuYrEjU5q6wsImZSbose+Gz5ptapjb1AE506GZG0CmjUNRwlAGHOGY16L 8SIBByrOGNh867wy7prMBoifwfjP6OMKQpw8DcKKmMGOpoc8ob5nw+ERf2FSCxym A8qgNRwVoRN4WMvcPcTNcCzhNnITqpNIFcy2ME0o9P1fI6ujgzQ= =KSE/ -----END PGP SIGNATURE-----pgpD9JUpepeCo.pgp
Description: PGP signature
--- End Message ---