Bug#994275: Reverting breaking changes in debianutils
On Wed, Sep 15, 2021 at 09:20:34AM +0200, Helmut Grohne wrote:
> On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
>...
> > 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.
This is a misrepresentation of my request.
I was making the case that making this specific widely used program
non-essential would bring "close to zero benefits" due to its size.
I was even writing:
> > As Helmut Grohne has demonstrated in recent years it is possible to
> > remove functionality from the Essential without causing breakage when
> > done carefully.
Everything regarding this point was worded with the intention to limit
the scope only to "which", not a general banning of shrinking of
essential.
>...
> > 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.
Are you arguing for a transition that makes "which" non-essential,
or are you arguing for a transition that would remove "which" from
Debian?
"deprecation" implies intended removal at some point in the future.
> > 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.
The current implementation is something where the maintainer has to be
overridden to prevent breakage.
Currently there would be a clear violation of policy during bullseye
to bookworm upgrades due to the program "which" that is part of the
essential set not being available between unpack and postinst.
If really required there might be hacks that could fix this problem.
But what is the long-term goal?
awk needs alternatives since there are permanently more than
two implementations in the archive, that might all be installed
at the same time.[1]
With the deprecation warning the debianutils maintainer gives the
impression that the intended number of "which" implementations in
Debian would be zero.
> > 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.
I agree with you that removal might in general be desirable in this case,
and that my request about criticism with the process should not be eternally.
I am changing this to:
The debianutils package must continue to provide the "tempfile" program,
unless removal follows a transition plan approved by the chair
of the Debian Technical Committee.
> > 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.
I wouldn't have gone to the TC only for this point,
and this point is only temporary.
> 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.
Points 2-5 in my request should be listed explicitly,
with that change it would be a good short-term injunction.
> 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.
This does not work with a maintainer who is not being constructive.
"majority of resulting issues" sounds like an invitation to not fix
everything, and "presented to debian-devel@lists.debian.org" does not
include a requirement that anyone has to approve it.
The widespread breakage by the debianutils changes is known to the
maintainer but has not resulted in reverting the breaking changes.
After the debianutils maintainer said missing upstream support was a
problem for the current "which" script, the maintainer of another
essential package offered to adopt the tiny "which" script from
debianutils into his package. This was rejected.
> Helmut
cu
Adrian
[1] and because it's a virtual essential package
Reply to: