Bug#994275: Reverting breaking changes in debianutils
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
Reply to: