[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#994275: Draft resolution for reverting changes in debianutils



Hello,

On Wed 13 Oct 2021 at 07:37PM -03, David Bremner wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> 1. Offer advice:
>
>>    The debianutils package must continue to provide the which(1) program
>>    until a compatible utility is available in a package that is at least
>>    transitively essential in Debian 12.
>
> Is it really advice if we say "must"?

The point here is just that the maintainer has not dropped which(1) so
it is not the case that we are overruling the maintainer, unlike in the
other points.  Perhaps we could label it as falling under 6.1.1 instead?
That's still distinct from 6.1.4.

>> 2. Overrule maintainer of debianutils:
>>
>>    The which(1) program must not print any deprecation warnings.
>
> I remain to be convinced on this point.

Okay.  Procedurally, what I think we should do here is have two options
other than FD on the ballot, with and without this particular bit of the
resolution.

> If I understand the issue correctly the problem is with autopkgtests
> failing because they were not expecting output on stderr. I don't
> think people are really entitled to expect which(1) to never print to
> stderr. Even when debian-policy recommended 'which' it apparently
> recommended redirecting stderr.
>
> I also don't see failures of autopkgtests as directly impacting users in
> the same way a failure to build or a failure to install does.
>
> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

As Raphael has mentioned, it's unlikely that when debianutils' which(1)
has been replaced with one in another essential or transitively
essential package that the new which(1), whether it's the same code or
something else, will print deprecation warnings.  And then it seems odd
to print them for a while and then stop printing them.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: