Package: tech-ctte Severity: normal This is a request to override the maintainer of debianutils on several changes that were done to the package in unstable after the release of bullseye.
More specifically, I am asking the Technical Committee to decide that: 1. The "which" program must be provided by an essential package. 2. The "which" program must not print any deprecation warnings. 3. The "which" program must not be provided through alternatives. 4. The debianutils package must continue to provide the "tempfile" program. 5. Programs in debianutils must not be moved to /usr unless there is project-wide consensus on packages doing such a move, and premature moving must be reverted. Rationale: The uncopordinated and mostly unnecessary changes to debianutils that should be reverted have already caused quite some amount of breakage and extra work for Debian developers, as well as breakage for users of unstable. The release team has so far protected users of testing from the problem by blocking testing migration, but this is not a long-term solution. Debian policy section 3.8 says: Maintainers should take great care in adding any programs, interfaces, or functionality to essential packages. Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity. This states a responsibility for all maintainers of essential packages to maintain backwards compatibility. As Helmut Grohne has demonstrated in recent years it is possible to remove functionality from the Essential without causing breakage when done carefully. Debian policy section 6.5 says: postrm purge ... The postrm script is called after the package’s files have been removed or replaced. The package whose postrm is being called may have previously been deconfigured and only be “Unpacked”, at which point subsequent package changes do not consider its dependencies. Therefore, all postrm actions must only rely on essential packages and must gracefully skip any actions that require the package’s dependencies if those dependencies are unavailable. The postrm of a package can rely on programs in essential packages to be present. For purging there is no limit how long after removal the user might do that. It is technically possible that a user might purge a package removed in the 1990s today, and purging a package removed 10 years ago might not even be that rare. 1. The "which" program must be provided by an essential package. The implementation of the "which" program in debianutils is a 1 kB < 100 LOC shell script. Maintainance of keeping the existing functionality of such a tiny script working is trivial, and the benefits of removing it are close to zero. The reason for keeping "which" as part of the essential set is due to the perpetuity requirement in policy. There would be a strong argument against adding "which" or several other programs like for example the 40 kB "whoami" binary in coreutils to the list of essential programs in Debian, but this itself is not a reason for removing a program from the essential set after it was there in a stable release. An offer by the maintainer of another essential package to move the "which" program there was rejected by the debianutils maintainer. The amount of breakage making "which" non-essential would cause was already mentioned to the debianutils maintainer a year ago: https://lists.debian.org/debian-devel/2020/08/msg00150.html 2. The "which" program must not print any deprecation warnings. The deprecation warning is misleading, and it is actually what causes most breakage. For interactive usage, "which" is a common program many users (including me) are using daily for decades. It works, and there is no reason to use something else instead. The debianutils maintainer has so far not replied to the question in #993700 how users should replace usage of "which -a". There is a claim that "command -v" is POSIX and "which" is not. This is true. It is also true that the huge number of vastly divergent UNIX systems that motivated standardization in the 1980s and 1990s has been mostly replaced with Linux, and some recent software even makes the design decision to not support any non-Linux systems (systemd would be an example for that). Doing a breaking change solely for the sake of larger POSIX compatibility without any clear real-world benefits in the year 2021 does not make sense. Looking at #993582, "which" actually seems to be more portable than "command -v" in practice. For non-interactive usage, "which" printing a deprecation warning is breaking many scripts. autopkgtest default to fail on additional messages. https://buildd.debian.org/status/logs.php?pkg=deja-dup&ver=42.8-1 would be an example for a FTBFS caused by the deprecation warning (green are ports buildds building with nocheck), #993244 another one. The deprecation warning causes similar breakage for scripts used by our users. 3. The "which" program must not be provided through alternatives. debianutils 5.1-2 contains the following change: * Manage `which` through alternatives so people can package FreeBSD which and GNU which as replacements. Debian policy section 3.8 says: Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. In the current state debianutils would fail this requirement, which might break upgrades from bullseye to bookworm. It is also incorrect that the essential "which" in debianutils would have to use alternatives if someone would want to package a more featureful different "which" implementation. A different "which" implementation doing dpkg-divert of the essential "which" script would be a more logical option. 4. The debianutils package must continue to provide the "tempfile" program. The perpetuity requirement also applies to the removal of "tempfile". Different from "which" an eventual removal of "tempfile" might be desirable, but this would have to be done in a coordinated manner by first getting all reverse dependencies fixed in a stable release instead of the current situation where the program was removed breaking reverse dependencies. Any properly planned removal would also have to analyse whether the purge problem based on policy section 6.5 mentioned above exists for any package that was shipped in a past Debian release. Example bugs for breakage caused removal of "tempfile" in an uncoordinated manner: #992399 #993621 #992455 #993722 #992442 #992915 #992733 #992457 #992458 #992454 5. Programs in debianutils must not be moved to /usr unless there is project-wide consensus on packages doing such a move, and premature moving must be reverted. The "run-parts" and "installkernel" programs were moved to /usr causing breakage. Whatever is being done regarding the merged /usr situation should follow a Debian-wide plan, individual packages moving files around in an uncoordinated manner only make things worse. Example bugs for breakage caused by this moving of files to /usr in an uncoordinated manner: #992425 #992649 #992615 #992481 #992639