Bug#994275: Draft resolution for reverting changes in debianutils
Hello, On Wed 13 Oct 2021 at 07:37PM -03, David Bremner wrote: > Sean Whitton 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 signature.asc Description: PGP signature
Bug#994275: Draft resolution for reverting changes in debianutils
Re: Adam Borowski > I'm even considering a MBF to go the _other_ way: change all but most > obviously correct uses of `command -v` to `which`. Please just don't. Christoph
Bug#994275: Draft resolution for reverting changes in debianutils
On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote: > There have been other reports of failures due to the message on stderr, > autopkgtest is not the only one (wookey mentionned a build failure). > > In any case, a message saying that which is deprecated when in fact > `which` will stay around (but maintained in another packages) is not > helpful. I'm even considering a MBF to go the _other_ way: change all but most obviously correct uses of `command -v` to `which`. The former is a footgun when a shell has extra builtins -- and eg. busybox sh has the world builtin. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#994275: Draft resolution for reverting changes in debianutils
Hi, On Wed, 13 Oct 2021, David Bremner wrote: > >The which(1) program must not print any deprecation warnings. > > I remain to be convinced on this point. 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. There have been other reports of failures due to the message on stderr, autopkgtest is not the only one (wookey mentionned a build failure). In any case, a message saying that which is deprecated when in fact `which` will stay around (but maintained in another packages) is not helpful. > 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. I think it does. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#994275: Draft resolution for reverting changes in debianutils
On 2021-10-13 19:37 -0300, David Bremner wrote: > Sean Whitton writes: > >The which(1) program must not print any deprecation warnings. > > I remain to be convinced on this point. If I understand the issue > correctly the problem is with autopkgtests failing because they were not > expecting output on stderr. It's not just that. Builds fail too. tensorflow now FTBFS in unstable because of this change, and the way bazel deals (or fails to deal) with it. I gave details further up the thread. > 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. I think causing build failures is enough reason to say this. I don't suppose that mine is the only one. Yes those builds are buggy and should not do this, and we should make efforts to find out why bazel (or possibly the build scripts it is operating on) is/are so crappy, but for now I agree that reverting this is the right thing to do. We have time to do this transition properly and quietly in the background, without causing random breakage. A message about a binary moving from one package to another does not need to be printed on every usage of that binary. Indeed it is actively unhelpful to do so. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#994275: Draft resolution for reverting changes in debianutils
Sean Whitton 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"? > 2. Overrule maintainer of debianutils: > >The which(1) program must not print any deprecation warnings. I remain to be convinced on this point. 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.
Bug#994275: Draft resolution for reverting changes in debianutils
Dear all, We think we might have a consensus on the following resolution text. We could be wrong, as the judgement of consensus has been made by just a few of us. We agreed in our meeting today that I'll start a vote a week from today unless a ctte member asks for a delay. Thus, we expect to close this bug approximately two weeks from today. Many thanks to Simon for a previous draft of this text. ~=~=~=~=~ 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. For the Debian 12 release, we expect which(1) to be in either an Essential package or a transitively Essential package (that is, a package that is depended on by an Essential package). 2. Overrule maintainer of debianutils: The which(1) program must not print any deprecation warnings. 3. Decline to overrule maintainer regarding use of alternatives: If another package takes over responsibility for which(1), then the debianutils maintainers and the other package's maintainers should coordinate to choose a suitable mechanism, which might be either versioned Depends/Breaks/Replaces, dpkg-divert, alternatives or something else. 4. Overrule maintainer of debianutils: The debianutils package must continue to provide the tempfile(1) program until a compatible utility is available in a package that is at least transitively essential in Debian 12. For the Debian 12 release, we expect tempfile(1) to be in either an Essential package or a transitively Essential package. 5. Overrule maintainer of debianutils: Programs in debianutils must not be moved to /usr until we have a project-wide consensus on going ahead with such a move, and any programs that have already been moved must be moved back. In particular, this means debianutils must contain /bin/run-parts and /sbin/installkernel for the time being. ~=~=~=~=~ -- Sean Whitton signature.asc Description: PGP signature
