Bug#994275: Reverting breaking changes in debianutils
On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
> 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.
As someone being involved with debianutils lately (via DPKG_ROOT), I
feel the need to share a slightly different point of view.
> 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.
While I do not see consensus about the "unnecessary" aspect yet, I do
see the extra work part. To the best of my knowledge the extra work part
has been clearly communicated to the which maintainer and it is quite
indisputable. I suppose that most of us can agree that the way the
changes are done here is not a good example of how to do them. The
process left many annoyed.
As such, I ask the committee to consider a further position: If a ruling
is needed, a possible outcome could also be overriding the debianutils
maintainer on the process aspect asking for a temporary revert until the
resulting issues have been proactively resolved.
This also highlights that we're again in a situation where a rapid
initial decision would be useful. The longer we let this go on, the more
work will shifted to fellow developers. Possibly, it would make sense to
split this request into a short-term and a long-term decision.
Unfortunately, we know the committee to be a slow-moving body from
experience, so my hope in arriving at a quick initial solution is low
indeed.
> 1. The "which" program must be provided by an essential package.
This request seems overzealous to me. Banning the shrinking of essential
would set a bad sign in my opinion.
That said, I completely agree that the process used to perform the
change leaves quite a bit to be wished for. As I see it, the real issue
with the removal is not that it is being done. Few people have a
personal relationship to which. The majority of grief arises from how
the work is distributed. It genuinely makes Debian work not-fun to some
and slightly annoys a lot.
> 2. The "which" program must not print any deprecation warnings.
The request for this decision again is rooted in the amount of work that
was caused to others. I am unsure whether the request being made here is
too specific and leaves too little room for actually performing the
transition in a sane way.
> 3. The "which" program must not be provided through alternatives.
I disagree with this. There is prior art for using alternatives in
essential packages, e.g. /usr/bin/awk. This hasn't been a problem
earlier.
> 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.
While it is difficult to disagree with this reasoning, I'm unsure
whether it is sufficient reason to override a maintainer.
> 4. The debianutils package must continue to provide the "tempfile" program.
The request asks for tempfile being kept eternally, but the reasoning
does not:
> 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.
Again, the criticism is with the process, not with the outcome.
> 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.
We still have a quite similar change in debhelper that moves around
systemd.service files and do not see a need to overrule the maintainer
there even though that also caused breakage. I do not think that raising
this issue with debianutils only at this time is appropriate. Indeed, it
seems to be a direct result and reasonable interpretation of an earlier
ctte decision, that now results in a similarly poor transition. If
anything, that decision needs to be updated.
As a consequence, I ask the ctte to quickly rule on the process aspect
of the issue and slightly defer the more difficult questions. The longer
we wait, the more harm is caused.
A possible outcome could be:
1. debianutils needs to temporarily revert changes that cause breakage
elsewhere including the deprecation of which and removal of
tempfile.
2. Before including the changes in debianutils again, a transition plan
must be presented to debian-devel@lists.debian.org. It must ensure
that the majority of resulting issues are fixed in unstable before
including the changes in the debianutils package.
Helmut
Reply to: