Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello Raphael,

On Tue 02 Nov 2021 at 08:31AM +01, Raphael Hertzog wrote:

> On Mon, 01 Nov 2021, Sean Whitton wrote:
>> Of course we should be exploring the new avenues that you mention.  But
>> becoming more willing to break unstable/testing than we are at present
>> might also be good for our project.
>
> Maybe, maybe not. What are you basing your assertion on?
>
> From my (limited) point of view, Debian testing/unstable is used by many
> derivatives because it's largely usable and stable, and we do get many
> contributions due to this.
>
> I for one contribute many fixes to Debian because Kali is built on Debian
> testing. At some point it was based on Debian stable and I was largely not
> able to contribute to Debian, and if we did break testing/unstable more
> often, the net result would likely that Kali would switch back to stable.
>
> I don't really see any scenario where breaking unstable/testing helps us
> in any way. Except if the breakage is really limited in time, and if the
> breakage does not affect upgrade paths, etc. But then I would no longer
> call that "breaking unstable/testing".

Thank you for bringing up derivatives, that's important.

The sort of situation I have in mind is where avoiding breaking unstable
results in a highly complex, drawn out and demotivating process, as
compared with just breaking unstable.  As we are mostly volunteers,
these sorts of considerations matter more than they might in other
organisations.  Thus, I am wary of categorically ruling out breaking
unstable as one of our options.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Raphael Hertzog]

On Mon, 01 Nov 2021, Sean Whitton wrote:
> Of course we should be exploring the new avenues that you mention.  But
> becoming more willing to break unstable/testing than we are at present
> might also be good for our project.

Maybe, maybe not. What are you basing your assertion on?

From my (limited) point of view, Debian testing/unstable is used by many
derivatives because it's largely usable and stable, and we do get many
contributions due to this.

I for one contribute many fixes to Debian because Kali is built on Debian
testing. At some point it was based on Debian stable and I was largely not
able to contribute to Debian, and if we did break testing/unstable more
often, the net result would likely that Kali would switch back to stable.

I don't really see any scenario where breaking unstable/testing helps us
in any way. Except if the breakage is really limited in time, and if the
breakage does not affect upgrade paths, etc. But then I would no longer
call that "breaking unstable/testing".

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello,

On Fri 29 Oct 2021 at 09:57AM +02, Raphael Hertzog wrote:

> I have sympathy with your reasoning and I can certainly relate to things
> that we did 20 years ago, where we happily broke unstable after a release
> but we have changed.
>
> Yes, on some aspects we have become more conservative. I certainly wish
> to change that, but not by going backwards, but by providing new avenues
> to experiment and make large-scale changes without breaking unstable/testing.

I'd like to express disagreement with the characterisation that breaking
unstable/testing more often for the sake of making major changes would
always count as going backwards.

Of course we should be exploring the new avenues that you mention.  But
becoming more willing to break unstable/testing than we are at present
might also be good for our project.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Raphael Hertzog]

On Sun, 24 Oct 2021, Clint Adams wrote:
> > 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.
> 
> Tell me, what would be helpful?

A coordinated take over of the binary with a proper transition as
recommended by the tech-ctte.

I have sympathy with your reasoning and I can certainly relate to things
that we did 20 years ago, where we happily broke unstable after a release
but we have changed.

Yes, on some aspects we have become more conservative. I certainly wish
to change that, but not by going backwards, but by providing new avenues
to experiment and make large-scale changes without breaking unstable/testing.

> On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> > 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.
> 
> I find this to be a curious statement.  This implies a contract of
> future behavior that does not exist.

Right, but that's we are doing in Debian when we discuss together and make
plans for further changes and then try to stick to the plan. You seem to
consider Debian as a more "organic entity" that is not controllable and
that you have no chance to influence.

And as often, the reality is somewhere in the middle.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Tue, Oct 26, 2021 at 09:53:55PM +0200, Thorsten Glaser wrote:
> “It only exists if it’s in Debian.”
> 
> SCNR. But this is relevant, here.
> 
> [ overly harsh words deleted ]

That's right, so we print a deprecation warning at the beginning
of the development cycle to raise awareness of the situation and
this leads to the interested parties packaging the whiches they
want to see in Debian over the subsequent ~2-year period.

This didn't work for tempfile because everyone still using tempfile
seems to redirect stderr to /dev/null and never saw the warning.

Ironically, it seems it hasn't yet worked for the original catalyst,
but it has worked for GNU which, modulo the problem of the NEW
queue.  As a side effect, it seems to have shined a spotlight on
some broken build systems.

Bug#994275: Reverting breaking changes in debianutils

[Thorsten Glaser]

On Tue, 26 Oct 2021, Clint Adams wrote:

> effort maintaining a utility which is superfluous given the
> existence of alternatives which are preferred by people who care

“It only exists if it’s in Debian.”

SCNR. But this is relevant, here.

[ overly harsh words deleted ]

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Tue, Oct 26, 2021 at 12:46:43PM +0200, tito wrote:
> It is possible to create a single command package if somebody
> will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
> tempfile is missing tough.

If someone wants to do that, I suppose they can.

On Tue, Oct 26, 2021 at 01:53:29PM +0100, Wookey wrote:
> I didn't understand why you wanted to make this change in the first

I think I tried to explain this to you on another mailing list.
There are people who are dissatisfied with the status quo with
respect to which(1).  I, as a user, don't care at all about
which(1).  I, as debianutils upstream, do not want to spend any
effort maintaining a utility which is superfluous given the
existence of alternatives which are preferred by people who care
about this stuff.

Now, as a debianutils maintainer in Debian, I could choose between
various different approaches, taking into account different objectives
to accommodate different stakeholder groups.  It is important to
acknowledge that it is impossible to please all groups here.

One approach is to embrace the status quo.  which(1) is perfectly
fine as it is, and anyone who wants `which -s` or
`which --read-functions` is a fool, an idiot, or worse.  Those
people don't matter and they should shut up.  I believe that this
is roughly equivalent to the original demand at the start of this
bug report.  I'll call this the ultraconservative approach.  It is
predicated on bad values and produces a bad outcome.

Another is to cautiously embrace change at a glacial pace.  This
signals to people who want something else that they are largely
unimportant, but as a gesture of good will, they can be accommodated
eventually, maybe in 2 years, maybe in 10.  It might seem reasonable
in a subculture which is stratified and resistant to change, with
stability (even the stability of _unstable_) paramount.  I'll call
this the conservative approach.  It is predicated on bad values and
produces a bad outcome.

Another is to build a runway for people to get what they want and
remove myself from the equation.  This is what I have attempted to
do.  Now, provided anyone elects to maintain them and the FTP team
allows them in, users will be able to install and use GNU which,
*BSD which, busybox which, rewrite-it-in-rust which, or whatever
should float someone's boat.  I can think all of this is pointless,
and it doesn't matter, because I am not impeding anyone else in
their pursuit of which(1) apotheosis.

> place, and I don't understand why you didn't just revert the message
> when it became clear that it was a problem, and I don't understand why
> you are still trying to justify your somewhat bloody-minded approach
> to this (should-have-been) minor issue, even after the tech comittee
> have agreed that it was not a good approach.

You seem angry that I haven't expended effort to work around a bug
in some other software.  You also seem angry that I am not following
a process that I am explicitly calling a bad process.  Other people
have said that "this is the way Debian does things," but I have been
doing this for 25 years and I recall Debian doing things many different
ways.

I'll save my commentary on the quality of the TC's decision until after
they have made it.

> Please, just remove the deprecation message, until GNU which is in
> unstable (like you should have done a couple of months ago, when first
> asked), then work out how the transition should go such that no-one
> using which will actually notice or care. Then you can throw away the
> hated binary :-) and we can all be happy.

When will GNU which be in unstable?

Bug#994275: Reverting breaking changes in debianutils

[Wookey]

On 2021-10-24 19:08 +, Clint Adams wrote:
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > 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.
> 
> Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
> October, and neither GNU which nor *BSD which nor any other which
> alternative is in unstable.  Presumably one of these could have put
> a band-aid on your bazel problem, though of course any version of
> `which` might output things to stderr for a variety of reasons.

That package is the band-aid I am currently using, but (because it has
indeed not progressed through NEW yet, which is presumably down to
ftpmaster bandwidth) it's a hassle where I have to make sure it is
made available in the build environment each time.

> Lots of things broke between buster and bullseye.

Most of them broke by accident or for good reasons. You broke this
semi-deliberately, by deciding not to manage a quiet background
transition of the which binary to some other package, but to print
a deprecation message and let other people deal with the fallout. OK,
maybe you expected the change to be harmless, but you didn't revert it
once it became clear that this was not a good way to do the
transition.

IIUC the tech committee have now told you to do it properly, as a
managed transition. Good.

> Is the difference that these packages aren't Essential?

The difference from where I am standing is the attitude of the
maintainer to doing things properly vs causing other people
hassle. Nobody is making you remove/move which. If you want to
move/remove which then do it in a way that doesn't break other
people's stuff (as much as possible). In this case that really isn't
hard to do (just wait until GNU which passes NEW, and preferably file
bugs on packages that now need to depend on it).

I didn't understand why you wanted to make this change in the first
place, and I don't understand why you didn't just revert the message
when it became clear that it was a problem, and I don't understand why
you are still trying to justify your somewhat bloody-minded approach
to this (should-have-been) minor issue, even after the tech comittee
have agreed that it was not a good approach.

Please, just remove the deprecation message, until GNU which is in
unstable (like you should have done a couple of months ago, when first
asked), then work out how the transition should go such that no-one
using which will actually notice or care. Then you can throw away the
hated binary :-) and we can all be happy.

I understand that it's galling to have the TC tell you to take a
different approach, especially when you've doubled-down on your
approach, but I'm afraid the TC is correct here, so please, stop
arguing, do what's best for the project, and soon enough this will all
be over, and we'll all have what we want. And you may (or may not)
choose to reflect on the the point that we _could_ have got to exactly
the same point without this argument if you'd made different choices.

From my personal point of view this is solved short-term the moment
the deprecation message is gone in unstable, and long term as soon as
GNU which enters unstable.

I hope this is my last-ever word on this tiresome subject.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[tito]

On Sun, 24 Oct 2021 19:08:20 +
Clint Adams  wrote:

> On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> > No. You’re conflating “which ”, which indeed is mostly redundant
> > with “command -v”, with “which -a ”, which is NOT otherwise
> > available, and a very useful thing to have, and one which (heh, pun
> > not intended) I pretty much expect to exist on a system.
> 
> I can think of no reason why anyone would need to run `which -a`
> from a maintainer script.  For interactive use, csh (and tcsh)
> never had -a for `which`.  The reason that zsh has `which -a` is
> because it shares code with `whence -a`, which was taken from
> ksh in the '80s.  Of course there's no telling whether it would
> have evolved later on if it had been originally csh-compatible.
> 
> > I know that feeling… some package maintainers don’t seem to care about
> > warnings. But as something in an Essential package I fear it’s up to
> > you to ping them, time and time again, until they don’t depend on it
> > any more, instead of proactively removing it.
> 
> I disagree.  This is not a good system.  This is how you architect an
> ultraconservative culture that discourages people from fixing things.
> 
> On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> > i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> > postint script and its removal started blocking my apt upgrades.  i had
> > to copy tempfile over from a virt stuck on an older deb to get around it.
> > 
> > (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> > 
> > it would be useful to ensure no packages rely on something before
> > removing it...
> 
> The fix for pv-grub-menu is as follows:
> 
> ---8<---snip---8<---
> diff --git a/update-menu-lst b/update-menu-lst
> index f2ca1c7..2e01a39 100755
> --- a/update-menu-lst
> +++ b/update-menu-lst
> @@ -128,7 +128,7 @@ fi
>  # Default options to use in a new config file. This will only be used if 
> $menu_file
>  # doesn't already exist. Only edit the lines between the two "EOF"s. The 
> others are
>  # part of the script.
> -newtemplate=$(tempfile)
> +newtemplate=$(mktemp)
>  cat > "$newtemplate" <  # $menu_file_basename - See: grub(8), info grub, update-grub(8)
>  #grub-install(8), grub-floppy(8),
> @@ -443,7 +443,7 @@ howmany=$(GetMenuOpt "howmany" "$howmany")
>  memtest86=$(GetMenuOpt "memtest86" "$memtest86")
>  
>  # Generate the menu options we want to insert
> -buffer=$(tempfile)
> +buffer=$(mktemp)
>  echo $start >> $buffer
>  echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" 
> >> $buffer
>  echo "## by the debian update-grub script except for the default options 
> below" >> $buffer
> ---8<---snip---8<---
> 
> How much effort is involved with that?  I would guess that it is less than
> bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
> or bullying me into uploading a `tempfile` package that I do not wish to
> maintain.
> 
> On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> > Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> > updated tag description is now live on our website. [2]
> 
> Thanks.
> 
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > 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.
> 
> Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
> October, and neither GNU which nor *BSD which nor any other which
> alternative is in unstable.  Presumably one of these could have put
> a band-aid on your bazel problem, though of course any version of
> `which` might output things to stderr for a variety of reasons.

Hi,
there is busybox that has which compiled in and is available
in all repos :

$busybox which
BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND

and It does have command line option -a 

getopt32(argv, "^" "a" "\0" "-1"/*at least one arg*/);

even if the help says nothing about it.

busybox which -a sh
/home/tito/bin/sh
/bin/sh
 
It is possible to create a single command package if somebody
will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
tempfile is missing tough.

Hope this helps.

Ciao,
Tito

> Lots of things broke between buster and bullseye.  Even in stable,
> people are struggling with horrible i915 driver bugs.  Would it have
> been 

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> No. You’re conflating “which ”, which indeed is mostly redundant
> with “command -v”, with “which -a ”, which is NOT otherwise
> available, and a very useful thing to have, and one which (heh, pun
> not intended) I pretty much expect to exist on a system.

I can think of no reason why anyone would need to run `which -a`
from a maintainer script.  For interactive use, csh (and tcsh)
never had -a for `which`.  The reason that zsh has `which -a` is
because it shares code with `whence -a`, which was taken from
ksh in the '80s.  Of course there's no telling whether it would
have evolved later on if it had been originally csh-compatible.

> I know that feeling… some package maintainers don’t seem to care about
> warnings. But as something in an Essential package I fear it’s up to
> you to ping them, time and time again, until they don’t depend on it
> any more, instead of proactively removing it.

I disagree.  This is not a good system.  This is how you architect an
ultraconservative culture that discourages people from fixing things.

On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> postint script and its removal started blocking my apt upgrades.  i had
> to copy tempfile over from a virt stuck on an older deb to get around it.
> 
> (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> 
> it would be useful to ensure no packages rely on something before
> removing it...

The fix for pv-grub-menu is as follows:

---8<---snip---8<---
diff --git a/update-menu-lst b/update-menu-lst
index f2ca1c7..2e01a39 100755
--- a/update-menu-lst
+++ b/update-menu-lst
@@ -128,7 +128,7 @@ fi
 # Default options to use in a new config file. This will only be used if 
$menu_file
 # doesn't already exist. Only edit the lines between the two "EOF"s. The 
others are
 # part of the script.
-newtemplate=$(tempfile)
+newtemplate=$(mktemp)
 cat > "$newtemplate" <> $buffer
 echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> 
$buffer
 echo "## by the debian update-grub script except for the default options 
below" >> $buffer
---8<---snip---8<---

How much effort is involved with that?  I would guess that it is less than
bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
or bullying me into uploading a `tempfile` package that I do not wish to
maintain.

On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> updated tag description is now live on our website. [2]

Thanks.

On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> 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.

Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
October, and neither GNU which nor *BSD which nor any other which
alternative is in unstable.  Presumably one of these could have put
a band-aid on your bazel problem, though of course any version of
`which` might output things to stderr for a variety of reasons.

Lots of things broke between buster and bullseye.  Even in stable,
people are struggling with horrible i915 driver bugs.  Would it have
been reasonable to demand that bullseye's kernel be reverted to Linux
4.19 and kept there for 5-10 years until someone figured out the
drm issues?

My DreamPlug's audio device went from being card0 to card1, breaking
everything expecting it to be card0.  Would it have been reasonable
to revert Linux, ALSA userland, systemd/udev, and whichever other
packages until I found the time to figure out what changed and why?

Is the difference that these packages aren't Essential?  Or that the
bug is within the packages themselves instead of a reverse dependency?
Or that it involves a package build instead of ordinary operation?

On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 13 Oct 2021, David Bremner 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).

GNU which can output things to stderr.  FreeBSD which can output to stderr.
There is no guarantee that cjwatson which won't output anything else to
stderr.

> In any case, a message saying that which is deprecated when in fact
> `which` will stay around (but maintained 

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello,

On Sat 16 Oct 2021 at 05:50AM GMT, Clint Adams wrote:

> On Wed, Oct 13, 2021 at 01:05:50PM -0700, Sean Whitton wrote:
>>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.
>
> Could you define "a compatible utility"?

I think it would be equivalent to the sense of compatibility that's
relevant when deciding whether two utilities can share a name managed by
the alternatives system?  So, a utility which behaves the same as
cjwatson-which when invoked in the ways in which cjwatson-which is
validly invoked, possibly with some additional command line switches and
the like.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Felix Lechner]

Hi,

On Mon, Oct 11, 2021 at 1:45 AM Sebastian Ramacher  wrote:
>
> the lintian tag
> possibly-insecure-handling-of-tmp-files-in-maintainer-script still
> recommend "tempfile or mktemp".

Lintian's last remaining reference to 'tempfile' was dropped. [1] The
updated tag description is now live on our website. [2]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/af93172c7a9ef326a68fd337c5089c52b74eb3f5
[2] 
https://lintian.debian.org/tags/possibly-insecure-handling-of-tmp-files-in-maintainer-script

Bug#994275: Reverting breaking changes in debianutils

[James Cloos]

> "CA" == Clint Adams  writes:

CA> However, I don't think that this is reasonable for tempfile(1) unless
CA> someone is actually willing to package and maintain a tempfile(1).

just saw this..

i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
postint script and its removal started blocking my apt upgrades.  i had
to copy tempfile over from a virt stuck on an older deb to get around it.

(cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)

it would be useful to ensure no packages rely on something before
removing it...

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#994275: Reverting breaking changes in debianutils

[Thorsten Glaser]

On Sat, 16 Oct 2021, Clint Adams wrote:

> It is my hope that update-shells will obsolete add-shell and remove-shell

Huh, what’s update-shells?

Hm, apparently something new in sid. Ouch. If you really wish for
that, it’ll involve painful versioned Pre-Depends and a largish
diff for backports :/ and, I think, at least one release in which
both are present so removing a shell in a partial upgrade won’t
fail, aborting dpkg…

> run-parts is special in that it is roughly feature-complete and, as
> far as I am aware, there are no extant alternatives other than Red
> Hat's "fork" of debianutils run-parts as a shell script.  I could be
> convinced that it shouldn't be Essential though.

run-parts is used a lot, though, as it’s rather useful.

> ischroot is pretty flawed and I continually regret acquiescing to its

Huh? -v please. I use that for some decisions on $orkplace systems.

> dpkg.  which was only important for maintainer scripts when POSIX only
> specified alternatives like `type` and `command -v` in optional
> extensions.  Now which is only important to people using bash, it seems.

No. You’re conflating “which ”, which indeed is mostly redundant
with “command -v”, with “which -a ”, which is NOT otherwise
available, and a very useful thing to have, and one which (heh, pun
not intended) I pretty much expect to exist on a system.

> I think that this (short-term transitively Essential) is fine for
> which(1), especially if GNU which is the only which(1) to make it
> through NEW within the next year and a half.

Hmmh. I personally don’t care too much which which is there, as long
as it’ll support the two(!) common uses, though ofc I’d prefer BSD ☻
but having just one is perhaps less error-prone.

> I don't know whether to be offended by anyone not seeing things.  The
> stable version of tempfile(1) prints a deprecation warning.  I filed bugs.
> I sent patches.  All breaking changes were uploaded to unstable at the
> beginning of the development cycle so to maximize the available time for
> testing.  Some people did NMUs.

I know that feeling… some package maintainers don’t seem to care about
warnings. But as something in an Essential package I fear it’s up to
you to ping them, time and time again, until they don’t depend on it
any more, instead of proactively removing it.

(I even have to support dashisms in mksh-as-/bin/sh (the lksh binary,
actually) because some bugs are so widespread…)

> These seem like minor bugs in debian-policy and lintian.

ACK.

> > upgrade failures. At least for that case I would expect that all the
> > users are fixed in release $x and then tempfile could be removed in $x
> > + 1.

Indeed.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> I was under the impression that debianutils is (intended to be)
> a Debian-specific package with no separate upstream existence. Does
> it have releases other than "whatever is in unstable"? Is there an

Yes, one of the many changes that was on hold until the bullseye
release was addressing a (non-deb) downstream request to provide
signed tarballs[0].

> upstream maintainer distinct from its Maintainer and Uploaders, namely
> you and Manoj?

For now it is I.

> "debianutils should consist of utilities maintained in debianutils"
> seems slightly circular. Is there an intended scope for what's in
> debianutils, beyond "things that need to be Essential because they
> always used to be Essential"?

I think that you may have misparsed my sentence.

> I see that CONTRIBUTING documents some of the utilities in debianutils
> as being unsupported/pending deprecation, such that if new features are
> desired, contributors are asked to instead fork the utility and coordinate
> removal from debianutils (and presumably takeover by a new package, given
> their Essential status). Can we infer the utilities you want to continue to
> maintain are everything not on that list?

I would say more that the set of utilities I think should remain in
debianutils for the time being for one reason or another is everything
not on that list.

> debianutils currently has:
> 
> - add-shell, remove-shell, update-shells: Debian-specific(?)
>   maintainer-script infrastructure for maintaining /etc/shells,
>   analogous to how init-system-helpers maintains system services.
>   Clearly at least transitively Essential, because if they were a
>   separate package, the Essential dash and bash would depend on them.

It is my hope that update-shells will obsolete add-shell and remove-shell
as well.

> - ischroot, run-parts, savelog, which (and historically tempfile):
>   these seem more like general-purpose utilities than anything else,
>   and Essential from their wide use without an explicit dependency?
>   Of these, CONTRIBUTING describes ischroot, savelog and which as being
>   unsupported (deprecated or pending deprecation) but presumably
>   run-parts is not in that category?

run-parts is special in that it is roughly feature-complete and, as
far as I am aware, there are no extant alternatives other than Red
Hat's "fork" of debianutils run-parts as a shell script.  I could be
convinced that it shouldn't be Essential though.

ischroot is pretty flawed and I continually regret acquiescing to its
incorporation.  savelog is garbage, but is, as you point out, used by
dpkg.  which was only important for maintainer scripts when POSIX only
specified alternatives like `type` and `command -v` in optional
extensions.  Now which is only important to people using bash, it seems.

>   CONTRIBUTING calls out logrotate as being better than savelog, but
>   savelog gets used by Essential packages like dpkg, and I don't think
>   logrotate is necessarily suitable to be transitively Essential.

I don't have an opinion on that, but if dpkg wants to subsume savelog,
that would be fine by me.

> Yes, and in general I think that direction is fine, as long as the
> transition away from these utilities being in debianutils is done carefully.
> 
> mktemp and readlink were taken over by Essential coreutils, with
> a transitional Pre-Depends; sensible-* were moved to non-Essential
> sensible-utils, with a transitional Depends (making sensible-utils
> transitively Essential for one release) to ensure existing systems didn't
> lose them, and presumably some reasonable plan to ensure that dropping
> them from the Essential set wouldn't break existing packages.

I can't comment on the reasonableness of the plan, as I had nothing to
do with it.

> `command -v` is not always a valid substitute for which(1). For example,
> when Flatpak's test suite builds a tiny container that includes /bin/sh
> and /usr/bin/echo, it can't use `command -v echo` because that would
> find shell builtins as higher-precedence than their ordinary executable
> equivalents. In Flatpak's case, the test happens to be a bash script
> and so can use `command -P echo` or `type -P echo`, but those are
> bash-specific and not always available in a POSIX shell.

Originally, I avoided specifying a particular alternative in the
deprecation warning because the appropriate substitute does indeed
depend on what the user is trying to do.

> None of this implies that what we might call "debianutils upstream" needs
> to be responsible for which(1) and tempfile(1) *forever*; but removing
> functionality from Essential is disruptive, so I think the maintainers
> of debianutils *in Debian* (in practice the same people?)  have a
> responsibility to ensure that debianutils.deb either continues to provide
> the Essential functionality of previous versions, or pulls in a version
> of some transitively-Essential package that takes over the Essential
> 

Bug#994275: Reverting breaking changes in debianutils

[Sebastian Ramacher]

Hi Simon

On 2021-10-11 01:01:45 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> > The release team has so far protected users of testing from the
> > problem by blocking testing migration, but this is not a long-term
> > solution.
> 
> Adrian asked in #994275 for changes in several topics to be reverted:
> 
> - which(1) deprecation
>   - deprecation warnings on stderr
>   - management via alternatives
>   - possible future removal
> - tempfile(1) removal
> - installkernel(8) moving from /sbin to /usr/sbin
> - run-parts(8) moving from /bin to /usr/bin
> 
> Which of those topics were your reason for adding a "block debianutils"
> hint? Are there any of those topics whose resolution you would consider
> to be a prerequisite for letting debianutils migrate to testing again?

I don't care about which(1). My reason for blocking debianutils was the
tempfile(1) removal, but I suppose now I would add the last two points
to the list as well - but usrmerge is the topic of another CTTE bug
anyway.

> The hint references #992399, which is related to tempfile(1), but
> #992399 has been closed (via a merge with #992396, which was resolved by
> debianutils adding a versioned Breaks on x11-common versions that needed
> tempfile). Do the release team consider #992399 to have been adequately
> resolved, or do you consider debianutils to still have a RC bug?

I don't consider #992399 to be fixed. I specifically asked for a
coordinated transition for the tempfile removal in that bug. So far I
see no indication that this transition is coordinated in any way. As far
as I can tell, the current strategy is to hope that users of unstable
install a large enough set of packages to discover all the remaining
uses of tempfile in maintainer scripts. See #993621, #994877, #996099
(which I just filed after a grep for tempfile in /var/lib/dpkg/info) for
the latest examples.

I think it would have been easy enough to follow a more systematic
approach by processing the whole archive with piuparts to detect all the
remaining cases.

Additionally, Debian Policy 10.4 and the lintian tag
possibly-insecure-handling-of-tmp-files-in-maintainer-script still
recommend "tempfile or mktemp".

Beyond tempfile(1) in maintainer scripts, random uses of tempfile
are still being reported. See #995583 for the latest example. But also
for this case, I see no coordination.

> If debianutils reinstated tempfile(1) in bookworm, and removed it in
> testing/unstable after the release of bookworm, would the release team
> consider that to be an adequate transitional period?

Helmut has shown how to remove interfaces from the essential set with
e2fsprogs. But I think e2fsprogs was in a much better place when this
was done: the interesting interfaces were moved to util-linux and for
the remaining users of e2fsprogs it was easy enough to add dependencies.
tempfile(1) however is used in maintainer scripts with the potential for
upgrade failures. At least for that case I would expect that all the
users are fixed in release $x and then tempfile could be removed in $x
+ 1.

For all the other uses of tempfile, I'm currently lacking an overview.

Cheers

> 
> Thanks,
> smcv

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> The release team has so far protected users of testing from the
> problem by blocking testing migration, but this is not a long-term
> solution.

Adrian asked in #994275 for changes in several topics to be reverted:

- which(1) deprecation
  - deprecation warnings on stderr
  - management via alternatives
  - possible future removal
- tempfile(1) removal
- installkernel(8) moving from /sbin to /usr/sbin
- run-parts(8) moving from /bin to /usr/bin

Which of those topics were your reason for adding a "block debianutils"
hint? Are there any of those topics whose resolution you would consider
to be a prerequisite for letting debianutils migrate to testing again?

The hint references #992399, which is related to tempfile(1), but
#992399 has been closed (via a merge with #992396, which was resolved by
debianutils adding a versioned Breaks on x11-common versions that needed
tempfile). Do the release team consider #992399 to have been adequately
resolved, or do you consider debianutils to still have a RC bug?

If debianutils reinstated tempfile(1) in bookworm, and removed it in
testing/unstable after the release of bookworm, would the release team
consider that to be an adequate transitional period?

Thanks,
smcv

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

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

Bug#994275: Reverting breaking changes in debianutils

[Russ Allbery]

Simon McVittie  writes:
> On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:

>> The fact that 95% of my inbox consists of hatemail about the
>> interactive usage of `which` suggests a failure at the latter.

> I'm sorry you're receiving hatemail about this package, and that's not
> OK, but it's orthogonal to whether the changes discussed in this bug
> were the right thing for Debian.

I'm just a bystander but I want to offer some minor disagreement with this
point: If a maintainer is experiencing problems with maintaining a package
due to a component that they think is out of scope for that package,
acting to resolve those problems is an attempt to do the right thing for
Debian.  It would result in a happier maintainer, a package with a clearer
and more cohesive purpose, and less trouble with maintenance.

How this is done can cause other problems and there is lots of room for
disagreement that the net overall effect was the right thing for Debian,
and opportunity to find other transition plans that would more right for
Debian.  I don't think it prejudges the whole discussion, in other words.

But I also don't think it's orthogonal.  Lots of upset energy directed at
maintainers is bad for Debian, and realigning the wants of those users
with the interests of maintainers to defuse that unhappiness is right for
Debian.

I think one of the goals should be for the which utility in Debian to be
maintained by someone who cares about the which utility and is interested
in handling bug reports and requests concerning it.

-- 
Russ Allbery (r...@debian.org)  

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:
> > The package description uses the phrases "specific to Debian" and
> > "installation scripts of Debian packages".  The fact that
> > debianutils is used on non-deb operating systems suggests a failure
> > at the former.
> 
> Given its package description, I too am confused by other distributions
> having picked up debianutils (as it seems at least Arch and Gentoo have),
> but the packages found in non-Debian-derived distributions are not under
> our control.
>...

Yocto needs debianutils due to update-ca-certificates using run-parts.

> smcv

cu
Adrian

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:
> The package description uses the phrases "specific to Debian" and
> "installation scripts of Debian packages".  The fact that
> debianutils is used on non-deb operating systems suggests a failure
> at the former.

Given its package description, I too am confused by other distributions
having picked up debianutils (as it seems at least Arch and Gentoo have),
but the packages found in non-Debian-derived distributions are not under
our control.

> The fact that 95% of my inbox consists of hatemail
> about the interactive usage of `which` suggests a failure at the
> latter.

I'm sorry you're receiving hatemail about this package, and that's not
OK, but it's orthogonal to whether the changes discussed in this bug
were the right thing for Debian.

> debianutils should consist solely of utilities that are actually
> deserving of Essential status, that are maintained by debianutils
> upstream, and do not needlessly duplicate functionality provided by
> other sources.

I was under the impression that debianutils is (intended to be)
a Debian-specific package with no separate upstream existence. Does
it have releases other than "whatever is in unstable"? Is there an
upstream maintainer distinct from its Maintainer and Uploaders, namely
you and Manoj?

"debianutils should consist of utilities maintained in debianutils"
seems slightly circular. Is there an intended scope for what's in
debianutils, beyond "things that need to be Essential because they
always used to be Essential"?

I see that CONTRIBUTING documents some of the utilities in debianutils
as being unsupported/pending deprecation, such that if new features are
desired, contributors are asked to instead fork the utility and coordinate
removal from debianutils (and presumably takeover by a new package, given
their Essential status). Can we infer the utilities you want to continue to
maintain are everything not on that list?

debianutils currently has:

- add-shell, remove-shell, update-shells: Debian-specific(?)
  maintainer-script infrastructure for maintaining /etc/shells,
  analogous to how init-system-helpers maintains system services.
  Clearly at least transitively Essential, because if they were a
  separate package, the Essential dash and bash would depend on them.

- ischroot, run-parts, savelog, which (and historically tempfile):
  these seem more like general-purpose utilities than anything else,
  and Essential from their wide use without an explicit dependency?
  Of these, CONTRIBUTING describes ischroot, savelog and which as being
  unsupported (deprecated or pending deprecation) but presumably
  run-parts is not in that category?

  CONTRIBUTING calls out logrotate as being better than savelog, but
  savelog gets used by Essential packages like dpkg, and I don't think
  logrotate is necessarily suitable to be transitively Essential.

- installkernel: the Debian implementation of an integration hook that
  is expected to be invoked by the upstream Linux kernel build
  system, analogous to how LSB init scripts can expect to source
  /lib/lsb/init-functions and we provide a Debian implementation of that
  interface in lsb-base?

> Divestiture of mktemp, readlink, sensible-editor, sensible-pager,
> sensible-browser, tempfile, and possibly mkboot were adjustments
> toward a better debianutils.

Yes, and in general I think that direction is fine, as long as the
transition away from these utilities being in debianutils is done carefully.

mktemp and readlink were taken over by Essential coreutils, with
a transitional Pre-Depends; sensible-* were moved to non-Essential
sensible-utils, with a transitional Depends (making sensible-utils
transitively Essential for one release) to ensure existing systems didn't
lose them, and presumably some reasonable plan to ensure that dropping
them from the Essential set wouldn't break existing packages.

mkboot doesn't have a replacement that I know of, but it seems like the
sort of utility that had a very limited use by the time it was removed,
so I'm happy to trust your judgement on what the appropriate time was to
remove it ("your" referring to you and Manoj as a team here - I know it
was actually Manoj who removed that one).

However, I don't think which(1) and tempfile(1) are really in the same
situation as all those. From my point of view, debianutils which(1) has a
lot in common with sysvinit-utils pidof(8): if we were defining Essential
today, those programs likely wouldn't be in it, and they should probably
be used a lot less than they are (in favour of the command builtin and
pgrep, respectively); but the fact remains that they *are* in Essential,
and too widely-used (by packages with no dependency, because Essential)
for a mass-bug-filing to be straightforward.

which(1) and tempfile(1) suffer from this somewhat worse than pidof,
because "which" is a common English word and "tempfile" is a common
name for variables, so locating users of those 

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Sat, Sep 25, 2021 at 11:31:41AM +0100, Simon McVittie wrote:
> This seems a good opportunity to ask what I think is a key question here:
> what do you consider debianutils' mission to be?

The package description uses the phrases "specific to Debian" and
"installation scripts of Debian packages".  The fact that
debianutils is used on non-deb operating systems suggests a failure
at the former.  The fact that 95% of my inbox consists of hatemail
about the interactive usage of `which` suggests a failure at the
latter.

debianutils should consist solely of utilities that are actually
deserving of Essential status, that are maintained by debianutils
upstream, and do not needlessly duplicate functionality provided by
other sources.

Divestiture of mktemp, readlink, sensible-editor, sensible-pager,
sensible-browser, tempfile, and possibly mkboot were adjustments
toward a better debianutils.

mktemp and readlink have been replaced by superior versions.
sensible-* live in a non-Essential package in which presumably
someone cares about them.  tempfile and mkboot are no longer
around to confuse people.  Did people see these things as
progress when they happened?  I would imagine that the people
who were verbally abusing me and flinging stop energy around
at the time did not.  Does anyone really miss the old debianutils
mktemp now?

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Sat, 25 Sep 2021 at 02:22:44 +, Clint Adams wrote:
>  * debianutils gets closer to achieving its mission, by having
>one fewer irrelevant utility that does not belong

This seems a good opportunity to ask what I think is a key question here:
what do you consider debianutils' mission to be?

smcv

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Fri, Sep 24, 2021 at 03:00:59PM -0700, Sean Whitton wrote:
> I thought what you wanted was to drop cjwatson-which, either in favour
> of no which in Debian at all, or the option to install GNU or BSD which.
> 
> However, you have now suggested that someone could package
> cjwatson-which in another package.  But in that case, what do you see
> removing cjwatson-which from debianutils as achieving?

I am merely pointing out that the current situation allows for
an infinite number of people to package an infinite number of
`which` alternatives, and no one has to get my permission or
coordinate with me.

Adrian has suggested that cjwatson-which is superior to any
currently proposed alternatives because of its file size.
I could not care less which `which` alternatives people want
to maintain because I have no use for /usr/bin/which.

Picture the happy path: GNU which successfully passes through
NEW.  A dozen people form a team to package FreeBSD which,
which also makes it through NEW.  bookworm is released, and
debianutils drops cjwatson-which.

 * Anyone who wants GNU which can install and use GNU which
 * Anyone who wants FreeBSD which can install and use FreeBSD which
 * `which` is no longer Essential, so people like me who don't want
   /usr/bin/which on their systems can have that too, because
   surely no one competent would choose to have a package depend
   on `which` when a standard POSIX utility can do a better job
 * The people who care not a whit about `which` no longer see that
   annoying deprecation warning being spewed by random scripts
 * All `which` alternatives in Debian will (probably) be maintained
   upstream, and also maintained downstream by people that care
   about `which`
 * debianutils gets closer to achieving its mission, by having
   one fewer irrelevant utility that does not belong

In this scenario, the GNU which enthusiasts are happy, the FreeBSD
which enthusiasts are happy, I am happy, and presumably Adrian
is unhappy.

So, then, what is the magic solution that will make all four groups
happy?

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello Clint,

On Fri 24 Sep 2021 at 12:52PM GMT, Clint Adams wrote:

> What I want is for GNU which to stop languishing in NEW, for the dozen
> people who keep complaining that FreeBSD which is better and some other
> volunteer should package FreeBSD which to actually spend the 15 minutes
> to do the work of packaging it, and if anyone wants to retain what I'll
> call "cjwatson which", to package that separately as well.
>
> Any subset of the above allows me to stop shipping which.debianutils
> post-release, and hopefully not install any which-providing package on
> my system.

I thought what you wanted was to drop cjwatson-which, either in favour
of no which in Debian at all, or the option to install GNU or BSD which.

However, you have now suggested that someone could package
cjwatson-which in another package.  But in that case, what do you see
removing cjwatson-which from debianutils as achieving?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Fri, Sep 24, 2021 at 09:26:19AM +0300, Adrian Bunk wrote:
> 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.

What I want is for GNU which to stop languishing in NEW, for the dozen
people who keep complaining that FreeBSD which is better and some other
volunteer should package FreeBSD which to actually spend the 15 minutes
to do the work of packaging it, and if anyone wants to retain what I'll
call "cjwatson which", to package that separately as well.

Any subset of the above allows me to stop shipping which.debianutils
post-release, and hopefully not install any which-providing package on
my system.

> 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]

I understand your confusion here: you seem baffled that I think that this
is a terrible idea on several levels but am claiming that I will not use
my divine-right-monarch-of-Debian powers to prevent the sysvinit-utils
maintainers from maintaining their package.  I, in contrast, am baffled
that you seem to think I have such powers.

> 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.

I don't have any idea what that means.

> 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.

Certainly going with my original plan would be even simpler, but that
would be effectively telling the people that want GNU which and FreeBSD
which that they would need to wait a few years before they can have what
they want.

> In [2] the debianutils maintainer has now suggested that doing 
> exactly this for "tempfile" would be tolerable for him.

Again, I think that this is a terrible idea, that it would annoy
me as a user, and that I have no intention of preventing anyone from
doing it even if I could.

> 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".

To use your word, that would be "tolerable".  However, I feel
compelled to warn the sysvinit-utils maintainers that they may
receive a flood of hatemail and be expected to explain to the
`which` enthusiasts why their needs and desires don't matter.

If they don't care about that, they can start shipping a `which`
alternative immediately.  I don't think anyone will send them
death threats if they ship `tempfile` too.  They do not need
my permission for these things.

> 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.

Policy §6.1 hints at why hard-coding paths to binaries is generally
a bad idea.

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

On Fri, Sep 24, 2021 at 10:44:06AM +0200, Ansgar wrote:
> On Fri, 2021-09-24 at 09:26 +0300, Adrian Bunk wrote:
> > 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".
> 
> There is an open bug asking for sysvinit-utils to no longer be
> essential[1]. With that in mind one should probably not move new stuff
> to it to keep it in the essential set.
> 
> (This is no argument for/against `which` and/or `tempfile` to be
> considered essential.)
> 
> Ansgar
> 
>   [1]: https://bugs.debian.org/851747


  - get moved to an existing Essential package, perhaps debianutils

Ouch.

I didn't mention that debianutils would not be the worst place and name 
for a random-stuff-that-is-essential-for-historical-reasons package
since that would not have been constructive here...

which+tempfile+sysvinit-utils combined is not much more than 100 kB
binaries in the essential set.

coreutils grew from 15.7 MB in buster to 17.5 MB in bullseye,
which has added literally more than an order of magnitude more to
the essential set than all these programs people want to remove.

After the release of bullseye, debianutils has added  
a nearly 4 kB "update-shells" to the essential set.

Compared to these I have not yet seen any reason (or clear maintainer 
statement) why removing the 1 kB "which" script from the essential set 
would be worth all the troubles all this has already caused in other 
packages, plus all future work it causes.

cu
Adrian

Bug#994275: Reverting breaking changes in debianutils

[Ansgar]

On Fri, 2021-09-24 at 09:26 +0300, Adrian Bunk wrote:
> 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".

There is an open bug asking for sysvinit-utils to no longer be
essential[1]. With that in mind one should probably not move new stuff
to it to keep it in the essential set.

(This is no argument for/against `which` and/or `tempfile` to be
considered essential.)

Ansgar

  [1]: https://bugs.debian.org/851747

Bug#994275: Reverting breaking changes in debianutils

[Thorsten Glaser]

On Fri, 24 Sep 2021, Adrian Bunk wrote:

> and assuming the sysvinit-utils maintainers agree, that they adopt
> both the existing "which" and (at least temporarily) "tempfile".

Independent of which “which” is to be adopted, I ask for this “which”
to be one that *does* support “which -a”, which is the one feature I
still use “which” for, instead of whence -p or command -v.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

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)

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello,

On Thu 16 Sep 2021 at 03:02PM -07, Sean Whitton wrote:

> 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.

This isn't quite right -- we could choose to implement some of your five
requests.  But this would not really yield an alternative transition
plan.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

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.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
> 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.

There is quite a lot in here and I disagree with most of it except for
the paragraph above.

However, I don't even know what this means:

> An offer by the maintainer of another essential package to move
> the "which" program there was rejected by the debianutils maintainer.

Because `which` (which I do not in any way view as part of
debianutils's core functionality) is now provided through
alternatives, an infinite number of essential packages could
provide their own `which` implementations and I don't know how
I would veto that even if I wanted to.

Similarly, if you want to move `tempfile` to another package, we can
transition that the same way `mktemp` was moved to coreutils.  You
could package the "original" `tempfile` or you could write a clever
little wrapper around `mktemp`.  I have opinions on this, but I will
keep them to myself because I won't be the one maintaining it.

Bug#994275: Reverting breaking changes in debianutils

[Helmut Grohne]

On Wed, Sep 15, 2021 at 12:41:31PM +0300, Adrian Bunk wrote:
> Are you arguing for a transition that makes "which" non-essential,
> or are you arguing for a transition that would remove "which" from 
> Debian?

Irrespective of the technical arguments for keeping or removing which, I
think that with a good transition removing which should not be out of
question. The actual reasons for or against doing so are less important
to me than using a process that doesn't annoy half of the developers.
For instance, I would love to ignore the /usr-merge, but I can't,
because it's breaking so much. At the point where we hardly notice the
transition, who am I to argue against it when I am unaffected?

> 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.

Thank you for explaining this in further detail. I do agree with this
and it should be documented as an rc-bug. However, it does not fully
rule out the use of alternatives. (It just feels stupid to continue
using them for all the reasons that you gave already.)

I've intentionally snipped much of your reply, because I don't think
there is much point in further discussion among us two. Consider that we
two are mostly in agreement about what I trimmed. After all, my main
point was to split a decision into a quick short-term one and a slow
long-term one. That seems to have come across.

Helmut

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> 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.

This part touches on an issue we are looking at in parallel to this
(#994388: more specific advice on merged-/usr).

I don't think it's a problem that there is an overlap between the two
tech-ctte bugs, because in #994275 you're asking for a maintainer to be
overruled, whereas in #994388 I am only asking for the technical committee
to offer advice; we should vote on those separately. Obviously it would
be unhelpful if the way in which we overruled or declined to overrule the
debianutils maintainer was inconsistent with our advice to the project as
a whole, so we need to be consistent, but that shouldn't be a problem :-)

I personally think we should have a moratorium on moving the logical
location of files from the directories affected by merged-/usr into /usr,
at least until we fully understand the implications, and perhaps for as
long as the whole Debian 12 development cycle.

smcv

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

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 

Bug#994275: Reverting breaking changes in debianutils

[Helmut Grohne]

On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
> 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.

As someone being involved with debianutils lately (via DPKG_ROOT), I
feel the need to share a slightly different point of view.

> The uncopordinated and mostly unnecessary changes to debianutils
> that should be reverted have already caused quite some amount of
> breakage and extra work for Debian developers, as well as breakage
> for users of unstable.

While I do not see consensus about the "unnecessary" aspect yet, I do
see the extra work part. To the best of my knowledge the extra work part
has been clearly communicated to the which maintainer and it is quite
indisputable. I suppose that most of us can agree that the way the
changes are done here is not a good example of how to do them. The
process left many annoyed.

As such, I ask the committee to consider a further position: If a ruling
is needed, a possible outcome could also be overriding the debianutils
maintainer on the process aspect asking for a temporary revert until the
resulting issues have been proactively resolved.

This also highlights that we're again in a situation where a rapid
initial decision would be useful. The longer we let this go on, the more
work will shifted to fellow developers. Possibly, it would make sense to
split this request into a short-term and a long-term decision.
Unfortunately, we know the committee to be a slow-moving body from
experience, so my hope in arriving at a quick initial solution is low
indeed.

> 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.

That said, I completely agree that the process used to perform the
change leaves quite a bit to be wished for. As I see it, the real issue
with the removal is not that it is being done. Few people have a
personal relationship to which. The majority of grief arises from how
the work is distributed. It genuinely makes Debian work not-fun to some
and slightly annoys a lot.

> 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.

> 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.

> 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.

> 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.

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.
 2. Before including the changes in debianutils again, a transition plan
must be presented to debian-de...@lists.debian.org. It must ensure
that the majority of resulting issues are fixed in unstable before
including the changes in the debianutils package.

Helmut

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

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.


Rationale:

The uncopordinated and mostly unnecessary changes to debianutils
that should be reverted have already caused quite some amount of
breakage and extra work for Debian developers, as well as breakage
for users of unstable.

The release team has so far protected users of testing from the
problem by blocking testing migration, but this is not a long-term
solution.


Debian policy section 3.8 says:

   Maintainers should take great care in adding any programs, interfaces,
   or functionality to essential packages. Packages may assume that
   functionality provided by essential packages is always available without
   declaring explicit dependencies, which means that removing functionality
   from the Essential set is very difficult and is almost never done. Any
   capability added to an essential package therefore creates an obligation
   to support that capability as part of the Essential set in perpetuity.

This states a responsibility for all maintainers of essential packages to
maintain backwards compatibility.

As Helmut Grohne has demonstrated in recent years it is possible to
remove functionality from the Essential without causing breakage when
done carefully.


Debian policy section 6.5 says:

  postrm purge
...
   The postrm script is called after the package’s files have been removed
   or replaced. The package whose postrm is being called may have previously
   been deconfigured and only be “Unpacked”, at which point subsequent
   package changes do not consider its dependencies. Therefore, all postrm
   actions must only rely on essential packages and must gracefully skip any
   actions that require the package’s dependencies if those dependencies are
   unavailable.

The postrm of a package can rely on programs in essential packages to be
present. For purging there is no limit how long after removal the user
might do that. It is technically possible that a user might purge a
package removed in the 1990s today, and purging a package removed
10 years ago might not even be that rare.


1. The "which" program must be provided by an essential package.

The implementation of the "which" program in debianutils is a 1 kB
< 100 LOC shell script. Maintainance of keeping the existing
functionality of such a tiny script working is trivial, and the
benefits of removing it are close to zero.

The reason for keeping "which" as part of the essential set is due to
the perpetuity requirement in policy. There would be a strong argument
against adding "which" or several other programs like for example the
40 kB "whoami" binary in coreutils to the list of essential programs
in Debian, but this itself is not a reason for removing a program from
the essential set after it was there in a stable release.

An offer by the maintainer of another essential package to move
the "which" program there was rejected by the debianutils maintainer.

The amount of breakage making "which" non-essential would cause
was already mentioned to the debianutils maintainer a year ago:
https://lists.debian.org/debian-devel/2020/08/msg00150.html


2. The "which" program must not print any deprecation warnings.

The deprecation warning is misleading, and it is actually what
causes most breakage.

For interactive usage, "which" is a common program many users
(including me) are using daily for decades. It works, and there
is no reason to use something else instead.

The debianutils maintainer has so far not replied to the question
in #993700 how users should replace usage of "which -a".

There is a claim that "command -v" is POSIX and "which" is not.
This is true.
It is also true that the huge number of vastly divergent UNIX
systems that motivated standardization in the 1980s and 1990s
has been mostly replaced with Linux, and some recent software
even makes the design decision to not support any non-Linux systems
(systemd would be an example for that).
Doing a breaking change solely for the sake of larger POSIX
compatibility without any clear real-world benefits in the
year 2021 does not make sense.

Looking at #993582, "which" actually seems to be more portable
than "command -v" in practice.

For non-interactive usage, "which" printing a deprecation warning
is breaking many scripts.

autopkgtest default to fail on additional messages.