Bug#994275: Reverting breaking changes in debianutils
On Thu, Sep 16, 2021 at 03:02:57PM -0700, Sean Whitton wrote:
> Hello Adrian,
>
> On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote:
>
> > 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.
>
> Roughly speaking, you're asking for a complete reversion of the change.
>
> Do you perhaps have a middle-ground proposal which would
>
> (i) accept the decision of the debianutils maintainer that which should
> be removed from the Essential set within a release cycle or so, but
> also would
>
> (ii) include a transition/deprecation plan which would impose less of a
> burden, from your point of view, on Debian contributors?
>
> The TC can't do detailed design work, so without such a proposal on the
> table, we're left deciding between a complete reversion and doing
> nothing at all. It would be good to have more options.
Talking about "which", it might be good to get an explanation from the
maintainer what he wants, and why, and then discuss based on that.
Your assumption that the decision of the debianutils maintainer is that
"which should be removed from the Essential set" is not clear, there
have been statements in both directions away from that.
Both the deprecation message and [1] imply complete removal from Debian,
not only removing it from the Essential set.
In the message [2] to this bug, the maintainer suddenly does not even
object to having a "which" in another essential package.
Trying to find a middle-ground proposal has already been attempted.
When the debianutils maintainer mentioned lack of upstream support and
annoyance by requests for additional features a month ago, a maintainer
of sysvinit-utils[3] offered to adopt the existing "which"
implementation there. This would have solved the stated problems - a
maintainer should not have to maintain software he does not want to
maintain. This was rejected with "well, hopefully it's going to stop
being Essential, because it shouldn't be".[4]
The alternative "which" implementations (GNU and BSD) are 30 kB binaries
instead of the current 1 kB script, enlarging the size of the Essential
set by that much feels like the exact opposite of making it non-essential.
Using the alternatives as the debianutils maintainer has now in this bug
suggested in [2] just for moving "which" do a different essential
package (like copying the implementation from debianutils to
sysvinit-utils) sounds unnecessarily complicated, and would require that
the debianutils maintainer fixes the race condition in debianutils when
upgrading from bullseye. The same can be achieved much simpler with a
seamless transfer of "which" to another package as was offered.
In [2] the debianutils maintainer has now suggested that doing
exactly this for "tempfile" would be tolerable for him.
In my opinion, an amicable middle-ground proposal would be that the
debianutils maintainer completely removes "which" from debianutils,
and assuming the sysvinit-utils maintainers agree, that they adopt
both the existing "which" and (at least temporarily) "tempfile".
I have not followed all recent discussions around merged /usr,
the TC knows better than me whether action is appropriate regarding
this point or whether it should be discarded.
> Sean Whitton
cu
Adrian
[1] https://sources.debian.org/src/debianutils/5.5-1/debian/NEWS/#L7
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994275#30
[3] a point can be made that this package is misnamed and even the
current contents would be better described by renaming it to
something like
random-stuff-that-is-for-some-reason-essential-and-mostly-unrelated-to-sysvinit
but that's a different topic
[4] as explained in my initial message, the case for keeping "which"
essential is not that it should be essential (that is debatable),
but the perpetuity requirement that it should stay essential because
it already is (or at properly transitioning it out of the Essential
set if someone really thinks it is worth the effort required for
doing that properly)
Reply to: