Bug#994275: Reverting breaking changes in debianutils
On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> More specifically, I am asking the Technical Committee to decide that:
I think this is really 5 separate (but related) requests, each of which
we could either uphold or decline, separately. Do you agree?
> 1. The "which" program must be provided by an essential package.
Constitutionally, I think this would have to be the TC formally offering
advice (under 6.1.5 in the Debian constitution), because the maintainers
of debianutils haven't attempted to remove "which", so there is not
yet any maintainer action that you want us to overrule.
For example, that advice could take the form of saying that if which(1)
is removed from debianutils in future, then we would expect that to be
accompanied by a suitable versioned dependency on a transitively-Essential
package that provides which(1) (either for bookworm, or indefinitely).
Does that sound right to you?
Or are you asking us to go further than that, and say that which(1)
can only be removed from debianutils if it is picked up by a different
Essential package?
> 2. The "which" program must not print any deprecation warnings.
I think that's a request to overrule the maintainer of debianutils
(under 6.1.4). I assume that was your intention?
> 3. The "which" program must not be provided through alternatives.
Also 6.1.4, I think.
> 4. The debianutils package must continue to provide the "tempfile" program.
Also 6.1.4.
Would you be equally happy with a TC resolution that keeps tempfile(1) in
the transitively-Essential set, but not necessarily via debianutils? For
example, we could consider saying that debianutils must either reinstate
tempfile(1), or add a dependency on some other (transitively Essential)
package that provides tempfile(1).
> 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.
Also 6.1.4.
smcv
Reply to: