Dear Maintainer,

util-linux supports two new commands irqtop/lsirq since v2.36.
The related release note: https://lwn.net/Articles/826866/

The irqtop(from util-linux) command has better user experience:
  - aggregate interrupt information seems clear on a morden server(128
    CPUs or more).
  - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
  - specify cpus in list format to monitor.
  - specify output columns to print.

The lsirq command supports:
  - specify output columns to print.
  - sort result.
  - raw/json/KV format to show.

Hi zhenwei pi,

* zhenwei pi <pizhenwei@bytedance.com> [220414 03:39]:

thanks for the reminder. For irqtop, I had some discussion with the
maintainer of the current irqtop package (CC'ed now). I cannot
remember if we came to a conclusion though. Axel, maybe you can
remind me...

lsirq - right, will probably put it into util-linux-extra soon. Or
do you think it should be part of the util-linux Essential API?

Chris

Hi, Chris

lsirq reads /proc/interrupts and shows the basic IRQ information of an
OS, it's a common and standard function. From the point of my view, to
be part of util-linux seems better. Please correct me if I misunderstand
the difference between util-linux and util-linux-extra package. Thanks!

Hi Chris, hi zhenwei,

Chris Hofstaedtler wrote:

Since you're asking, I allow myself to cite my reply to your inquiry
with me back then (June 2021):

---------------------------------------------------------------------

Hmmm, do they do the same? Can I test that irqtop from util-linux
somewhere?

Since people seem to expect the irqtop tool from util-linux, I see
multiple options:

1) If the irqtop from util-linux is clearly superior: Drop building
   the irqtop package from src:iptables-netflow and let util-linux
   generate a transitional package. (Versions should be no problem
   with 2.6 < 2.36.)

   I more or less built that binary package, because that tool was in
   the upstream sources and no such feature was present in Debian so
   far and I didn't want to pull in ruby just for a DKMS kernel module.

2) If none of them is clearly superior and they have different feature
   sets, using the alternatives system might be an option.

   Since I expect both to be just TUI tools without having an API
   being used by other tools, different commandline options should not
   be an issue here.

3) Rename one of them, e.g. to irqtop-nf or irqtop-ul or so. (Renaming
   both of them will be needed for variant 2 anyways.)

In case you intend to add lsirq for bullseye, you could also add
irqtop as irqtop-ul or so (i.e. variant 3b), too. That shouldn't cause
any disturbance IMHO.

---------------------------------------------------------------------

As far as I can see, I didn't get a reply back from you on these
suggestions of mine. Maybe my mail fell through the cracks. But I
think we should take the discussion up again, probably in this bug
report.

Another point which comes to my mind now is that it might make sense
to rename the current irqtop package to irqtop-nf (or irqtop-ruby)
just to make clear that it does not contain the irqtop tool from
util-linux.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Hi Axel, zhenwei,

* Axel Beckert <abe@debian.org> [220414 15:08]:

Thanks!

Right. I think I forgot to reply back then - sorry.

Experimental should have util-linux-extra 2.38-4+exp1 very soon,
with irqtop installed. Obviously this can only be used for testing.

Personally I think we should have only one irqtop - from my point of
view it does not matter which one. Maybe the new version is
superior. In any case we should not confuse our users.

zhenwei, do you have input on the differences between the existing
irqtop and the new irqtop from util-linux?

Might be an idea. But lets see what the differences are, first.


Thanks,
Chris

Hi, Chris & Axel

The main difference between the two versions:
- original irqtop shows separated interrupt information
- new irqtop shows aggregate interrupt information

Test env: Debian 10; 96 CPUs on a server, 230 characters per line in
termial.

- irqtop (original version) shows uncompleted interrupts(31 / 96 CPUs).
n194-087-081 - irqtop - 2022-04-15 09:42:48 +0800
               CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7
CPU8   CPU9  CPU10  CPU11  CPU12  CPU13  CPU14  CPU15  CPU16  CPU17
CPU18  CPU19  CPU20  CPU21  CPU22  CPU23  CPU24  CPU25  CPU26  CPU27
CPU28  CPU29  CPU30  C
   cpuUtil:     0.0    0.0    0.4    0.0    1.3    0.0    0.0    0.2
0.0    0.0    0.0    0.0    0.0    0.0    0.2    0.0    0.0    0.0
0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.2    0.2    0.2
0.2    0.0    0.2
      %irq:     0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0
     %sirq:     0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0
0.0    0.0    0.0
  irqTotal:      32    293    477      5     34      7      5   1805
112     51      3      2     28      2   1901      1     13     16
0      6      1     19      2      2     67     29     51     51     42
      9     34
i       9:       .      2      0      0      0      .      .      .
  .      .      .      .      .      .      .      .      .      .
.      .      .      .      .      .      .      .      .      .      .
      .      .
i      48:       .      .      .      .      .      .      0      .
  .      .      .      .      .      .      .      .      .      .
.      .      .      .      .      .      .      .      .      .      .
      .      .
i      49:       .      .      .      .      .      .      .      .
  .      .      .      .      .      .      .      .      .      .
.      .      .      .      .      .      .      .      .      .      .
      .      .
i      50:       .      .      .      .      .      .      .      .
  .      .      .      .      .      .      .      .      .      .
.      .      .      .      .      .      .      .      .      .      .
      .      .
i      51:       .      .      .      .      .      .      .      .
  .      .      .      .      .      .      .      .      .      .
.      .      .      .      .      .      .      .      .      .      .
      .      .


- irqtop (from util-linux) shows aggregate interrupt information.
irqtop | total: 575548749447 delta: 518913 | n148-134-075 | 2022-04-15
10:02:14+08:00

       IRQ        TOTAL     DELTA NAME

       LOC 218396041027    393883 Local timer interrupts
       RES 217686711923     50039 Rescheduling interrupts
       PIN  40532867503     10053 Posted-interrupt notification event
       CAL  15012540676      2013 Function call interrupts
       PIW  13810059255     57692 Posted-interrupt wakeup event
       TLB   8699607720      1597 TLB shootdowns
       221   4235495788        88 IR-PCI-MSI 50331656-edge eth0-4

Other enhanced features from the new version:
  - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
  - specify cpus in list format to monitor.
  - specify output columns to print.
  - enable/disable per-cpu statistics by specified mode.
  - performance improvement. New irqtop written by C uses a little CPU
when running 'irqtop -d 1', the Ruby version spends more time(quite
obvious on a 96 CPUs platform).

Hi Chris,

Chris Hofstaedtler wrote:

Happens…
But I was aware of it and uninstalled irqtop beforehand. :-)

Hmmmm.

Fully agree. Nevertheless, Debian is a lot about having choice between
different implementations (compared to e.g. Ubuntu). And choice
sometimes makes things less easier to understand.

Ack.

zhenwei pi wrote:

Thanks for that summary.

(I btw. just noticed that zhenwei is actually the author of
util-linux's implementation of irqtop:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d511011c
refers to https://github.com/pizhenwei/irqtop as previous place of
development. :-)

Hrm, interesting.


I currently only have access to boxes with 32 cores, but it shows all
of them and also some additional information in the last column which
seems to have been stripped from your instance due to probably the
limited terminal width. Mine looks like this and also has IRQ names
shown instead of numbers:

somehost - irqtop - 2022-04-15 15:13:12 +0000
              CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7   CPU8   CPU9  CPU10  CPU11  CPU12  CPU13  CPU14  CPU15  CPU16  CPU17  CPU18  CPU19  CPU20  CPU21  CPU22  CPU23  CPU24  CPU25  CPU26  CPU27  CPU28  CPU29  CPU30  CPU31
  cpuUtil:     0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    3.8    0.0   total CPU utilization %
     %irq:     0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0   hardware IRQ CPU util%
    %sirq:     0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0    0.0   software IRQ CPU util%
 irqTotal:       5      0      1      0      0      5      0      0      0      0      0      0      5      0      0     36      0      0      0      1      0      0      0      0      0      0      0      0      0      0     17      0   total hardware IRQs
i     117:       .      .      .      .      .      .      .      .      .      .      .      .      3      .      .      .      .      .      .      .      .      .      .      .      .      .      .      .      .      .      .      .   IR-PCI-MSI 4194317-edge      i40e-eno1-TxRx-12
i     LOC:       5      0      1      0      0      5      0      0      0      0      0      0      1      0      0     36      0      0      0      1      0      0      0      0      0      0      0      0      0      0     17      0    Local timer interrupts
s   TIMER:       5      0      0      0      0      7      0      0      0      0      0      0      1      0      0      1      0      0      0      1      0      0      0      0      0      0      0      0      0      0      0      0
s  NET_RX:       0      0      0      0      0      0      0      0      0      0      0      0      3      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0
s   SCHED:       5      0      0      0      0      7      0      0      0      0      0      0      1      0      0     33      0      0      0      1      0      0      0      0      0      0      0      0      0      0      9      0
s     RCU:       1      0      0      0      0      7      0      0      0      0      0      0      1      0      0      7      0      0      0      1      0      0      0      0      0      0      0      0      0      0     13      0

(I currently suspect that zhenwei used the irqtop from Debian 10
Buster, i.e. version 2.3 instead of the current version 2.6 as can be
found in Debian Unstable and Testing. That might have caused these
differences.)

That's quite a difference IMHO.

The from irqtop from util-linux though shows on my box also some per
CPU respectively per core stats (Debian Unstable, with irqtop from
Christian's util-linux-extra package version 2.38-4+exp1 from Debian
Experimental):

irqtop | total: 22014142315 delta: 9471 | c6 | 2022-04-15 16:47:26+02:00

        cpu0 cpu1 cpu2 cpu3
  %irq: 30.4 24.1 20.0 25.5
%delta: 36.1 18.5 16.5 28.8

            IRQ           TOTAL           DELTA NAME
            LOC     14019433563            6020 Local timer interrupts
            129      2573943707            1722 IR-PCI-MSI 520192-edge enp0s31f6
            RES      2091668263             575 Rescheduling interrupts
            130       794066902              17 IR-PCI-MSI 376832-edge ahci[0000:00:17.0]
            CAL       763171794             140 Function call interrupts
            138       612474851             790 IR-PCI-MSI 524288-edge nvkm
            128       463147433              67 IR-PCI-MSI 327680-edge xhci_hcd
            TLB       455459030               0 TLB shootdowns
            137       221045281             140 IR-PCI-MSI 514048-edge snd_hda_intel:card0
            131        19266170               0 IR-PCI-MSI 1572864-edge xhci_hcd
            NMI          198160               0 Non-maskable interrupts
            PMI          198160               0 Performance monitoring interrupts
            MCP           68615               0 Machine check polls
             17             217               0 IR-IO-APIC 17-fasteoi snd_hda_intel:card1

From my point of view, they seem to have quite a different feature
set. The main advantage of the irqtop from util-linux seems to be that
it is more readable with a lot of CPUs, but gives less detailed statistics.

The ruby-written irqtop does more detailed per-cpu/per-core statistics
— which might be helpful with a few cores, but you'll loose overview
with a lot of cores, as seen by zhenwei's "screenshot" which is
truncated at CPU 30.

Yeah, it's obvious, but the reason is not the 96 CPUs but the fact
that its written in an interpreted language and not compiled.

Anyway, IMHO we should:

* Figure out how to get the util-linux implementation into Debian
  proper.

* irqtop from util-linux should in some way become the future default,
  as its probably what the user usually expects. The ruby-written
  irqtop is only a niche tool written for analysing the performace of
  the ipt_NETFLOW.ko iptables plugin kernel module. (But seems to have
  been useful elsewhere, too, as probably shown by the fact that
  util-linux added a similar tool, which is probably less focussed on
  that one job. :-)

Regarding the ruby-written irqtop:

* It is currently endangered to be removed from testing by the
  horribly outdated ruby-curses (https://bugs.debian.org/958973) in
  Debian which is also no more maintained; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 and
https://bugs.debian.org/1009727 (Christian: I X-Debbugs-Cc'ed you on
  #1009727 for that and because I know that you're also active in
  Debian's Ruby packaging.)

* It has a higher popularity than I expected:
https://qa.debian.org/popcon-graph.php?packages=irqtop&show_installed=on&show_vote=on&want_legend=on&beenhere=1

Because I as user and Linux admin prefer having choice and because the
two irqtop implementations seem to rather different, I really would
prefer to keep the ruby-written irqtop in Debian nevertheless at least
for now.

My currently preferred variant (probably needs to be a bit more
polished) to go forward is:

* Renaming the current irqtop package (and binary) to irqtop-nf.

* Making a "irqtop" a transitional package which pulls in either
  irqtop-nf or util-linux-extra , i.e. has a

    Depends: irqtop-nf | util-linux-extra

  in its control file. That way those who upgrade automatically get
  the same implementation as before. But those who look at the package
  see that there are two choices.

* After the Bookworm release, the "irqtop" package should be removed
  and provided by the util-linux-extra package, so that those who do
  "apt install irqtop" actually get the more expected implementation
  from util-linux.

* I think we should also try to use /etc/alternatives/irqtop +
  update-alternatives with irqtop from util-linux-extra having the
  higher priority so that those who install both, get the probably
  more expected util-linux-extra's implementation by default.

In case you agree, I'd upload an updated iptables-netflow source
package to Debian Experimental implementing these changes so we can
cross-installability and upgrade paths.

		Regards, Axel

Hi Axel,

* Axel Beckert <abe@debian.org> [220415 17:53]:
[comparison between irqtop variants, my thanks to both of you]

(I understand this is "temporarily fixed" now.)

Right.

I think I agree with almost everything here. There is a small caveat
with regards to update-alternatives:

1) general question: do we get anything "actually useful" out of
using u-a?
Regardless of using u-a, (I think) util-linux would need to grow a
versioned Conflicts/Replaces/Breaks on irqtop.

2) If we settle on update-alternatives, irqtop from util-linux
really needs to be (and stay) in util-linux-extra. Some background:
util-linux is Essential: yes. -> I want util-linux to be relatively small,
contain only utilities that are useful on -all- installations, and
it should be "postinst free". All of this pretty much already says
util-linux-extra should have irqtop, and not util-linux.

So, if we go with update-alternatives, which program names do you
propose? irqtop-nf and irqtop-ul?
There is some precedent to use "." instead of "-", but probably
either are fine.

Chris

Hi Chris,

TL;DR: What if we just make util-linux-extra taking over the binary
path /usr/bin/irqtop and the irqtop(-nf) package providing a binary
name irqtop-nf in the future plus leaving the remainder to
package descriptions and NEWS.Debian?

Chris Hofstaedtler wrote:

Indeed. I was very surprised and happy that my poking of the (not-)
maintainers actually triggered an upload. :-)
ruby-written irqtop beforehand don't have to learn a new name.

There is one other possibility to provide that: Using dpkg-divert
instead of update-alternatives with util-linux(-extra) shipping irqtop
and irqtop diverting it away to irqtop-ul iff both packages are
installed.

This would have advantages and disadvantages:

Advantage:

* No special handling needed at all for util-linux or
  util-linux-extra.

Disadvantages:

* Less choice for the admin which package provides irqtop if both are
  installed. Then again that case usually only happens if someone has
  already installed irqtop (the package, i.e. the ruby-written one) or
  installs it on purpose.

* The concept of dpkg-divert seems less well-known than
  update-alternatives and might confuse users more often if they
  expect util-linux's irqtop in that package.

Most of the disadvantages could be fixed with making it clear in the
package description of the irqtop package that it's not util-linux's
irqtop implementation but a different one existing for a longer time
already.

Then again, I don't think the gain isn't worth the effort. See below

So that confusion (either with dpkg-divert or with renaming the
ruby-written irqtop binary to irqtop-nf and keeping it there) should
be limited to those users knowning about the ruby-written irqtop
implementation and not reading package descriptions and not reading
NEWS.Debian entries — which should the a very small group of users.
:-)

That (or for util-linux-extra) is needed anyways. (Except maybe if
src:util-linux produces an irqtop package, but nobody seems to have
considered that so far.)

I thought that was your plan anyways.

I see.

Ack.

Yes.

Just wanted to note the same, too. But I personally prefer the dash.
But see below.

Anyway, given all those thoughts and the context of util-linux being
an essential package, I changed my opinion and think we should proceed
as follows:

So far the same.

* I will add a note to the package description of irqtop(-nf) that
  it's not util-linux's implemenation but a different one and a
  NEWS.Debian entry that its contained binary name changed from irqtop
  to irqtop-nf and that also the package containing it changed its name.

This is all stuff on my side as far as I can see.

* From src:util-linux's side the only thing left is that the package
  shipping util-linux's implementation of irqtop needs to sport Breaks
  and Replaces (not Conflicts) against "irqtop (<< 2.6-4~)".

  If you want, I can file a RC bug-report against the version in
  Experimental due to its util-linux-extra package missing these
  headers so far.

* Optionally you could add a note in the package description of
  util-linux(-extra) that the previously known, ruby-written
  implementation of irqtop can be found in the package irqtop-nf.

I will soon prepare an upload to experimental implementing this in the
src:iptables-netflow package.

I'd be happy if you could fix the missing Breaks/Replaces headers in
util-linux-extra. TIA!

		Regards, Axel

Hi Axel,

* Axel Beckert <abe@debian.org> [220417 13:50]:

Thanks for the analysis and suggestions!

Both - the Breaks/Replaces, and the package description - are now in
experimental, as src:util-linux / util-linux-extra 2.38-4+exp2.
Would love your feedback on these changes.

Best,
Chris

Hi Chris,

Thanks. Looks good to me now. I though suggest to slightly rephrase
this sentence:

  Another variant of irqtop is found in the irqtop-nf package.

I suggest to phrase it more like this:

  A different implementation of irqtop can be found in the irqtop-nf
  package.

I'm working on the accompanying irqtop and irqtop-nf package, but will
probably upload it only after a round of sleeping (aka "tomorrow"
despite it's already "tomorrow" in my time zone ;-).

My work on it so far can be found on
https://salsa.debian.org/debian/iptables-netflow/ with most of it
being in this commit:

https://salsa.debian.org/debian/iptables-netflow/-/commit/85f7bb9ba685e7bfe5837c5aa476dfd8f5c3ec08

Also remember that it will have to go through the NEW queue due to the
additional binary package, i.e. it might take a week or so before it
shows up in experimental.

Not a comment on these changes, but still something I'm wondering
about:

Why does util-linux have a hard dependency on util-linux-extra?

I would have expected a Recommends or Suggests. Because otherwise
splitting off that package seems to make no sense to me.

And also the alternative dependency from the future irqtop
transitional package makes no sense as it will be always fulfilled
since currently util-linux-extra is a defacto essential package.

		Regards, Axel

* Axel Beckert <abe@debian.org> [220418 02:21]:

Yes, that sounds better. Will do, thanks.
important bits) got moved to -extra. I want to avoid surprises for
users that still need hwclock.

After bookworm I'll replace Depends with Suggests/Recommends.
Technically the Depends from irqtop to util-linux-extra is not
needed. I think it still makes sense to have it, in case the
relations between util-linux and util-linux-extra change before the
release.

Do you agree?

Chris

Hi Chris,

sorry that we're slightly drifting away from the irqtop topic (I
nearly wanted to type "irqtopic" :-) to more general transition
topics. Feel free to tell me if you want to have this discussion
elsewhere. (I allowed myself to remove at least zhenwei from the Cc
for that reason.)

Chris Hofstaedtler wrote:

If hwclock is such a relevant part of util-linux-extra (and that seems
the case, see below), it probably should be mentioned in the package
description. Actually. since I only see four commands plus the hwclock
infrastructure in it, I'd mention them all in the package description.
(Sorry for another round of package description nitpicking — wasn't
aware of hwclock being involved as I just looked on the list of
binaries under /bin/ and /usr/bin/ so far.)

IMHO Recommends should suffice there for end users who deliberately
need hwclock.

Recommends are installed by default, and if the user decides to not
install them — either by setting this as default or manually — that's
the user's problem and not the package's. (Mentioning such stuff in
the package description helps — except for those users who don't read
them. ;-)

And Recommends aren't uninstalled while upgrading (unless there's a
dependency conflict which I don't see here).

For other packages that really depend on it, there are transition bug
reports needed now to make them have a hard dependency on
util-linux-extra.

I'd use Recommends due to hwclock. Only containers and VMs don't need
it — and I currently expected most systems still be on real hardware
(although quite a bunch of SBCs like the Raspberry Pi doesn't have a
hwclock ex factory), but I maybe wrong.

Suggests IMHO only makes sense if the Debian Installer takes care of
installing util-linux-extra if it runs on real hardware and the
hardware has a RTC clock.

Since there are no transitional packages involved (which cause the
"automatically installed" flag not to be set for their dependencies by
default) I would expect the same problems, you don't want to see now,
just later.

From a short look, this would be the following 98 packages refering to
hwclock in some way according to
https://codesearch.debian.net/search?q=%5Cbhwclock%5Cb&literal=0

And I see no other essential package (besides obvious ones like
util-linux which I kicked out manually), but tons of near-essential
ones li.ke the Linux kernel, APT, glibc, most (IMHO all relevant) init
systems.

Then again, I did a few cross-check because some packages don't seem
to make sense to have a reference to hwclock. E.g. jc doesn't seem to
refer to hwclock in its binary package, just in its test suite in some
rather randomly chosen data:

→ dfgrep hwclock jc
→ apt-get source jc
[…]
→ cd jc-1.18.5
→ fgrep -rl hwclock
tests/fixtures/ubuntu-18.04/systemctl-luf.out
tests/fixtures/ubuntu-18.04/systemctl-luf.json
tests/fixtures/centos-7.7/ls-glob.out
tests/fixtures/centos-7.7/ls-glob.json
→

I assume that there will be many more such cases. I also don't expect
many (if at all any) cases where hwclock needed as build-dependency.
So we IMHO could focus on binary packages only. (Is there a service
like codesearch.debian.net which has the contents of all files in all
binary packages indexed?)

Anyway, here's the full list (with just util-linux removed for obvoius
reasons) according to codesearch.debian.net:

abs-guide
acpi-support
acpid
adjtimex
aide
android-platform-system-core
android-platform-tools
ansible
ansible-core
apt
aptly
autopkgtest
bash-completion
busybox
calamares
calamares-settings-debian
cdist
chromium
chrony
cinnamon-settings-daemon
clock-setup
cruft
debian-edu-fai
debian-handbook
debian-lan-config
debian-reference
debram
dracut
drbl
etckeeper
fai
fake-hwclock
finit
glibc
google-guest-agent
highlight
htpdate
initramfs-tools
insserv
ipmiutil
jc
kiwi
labgrid
lava
libgtop2
libguestfs
libvma
lintian
linux
live-config
ltsp
lxc-templates
manpages-fr-extra
manpages-ja
manpages-l10n
mate-settings-daemon
mc
monitoring-plugins-systemd
ntpsec
nvram-wakeup
open-build-service
open-infrastructure-system-tools
openrc
osinfo-db
packagekit
pbuilder
plasma-desktop
pm-utils
prelude-lml-rules
puppet
qemu
qt6-webengine
qtwebengine-opensource-src
rcconf
refpolicy
reprotest
rkhunter
salt
shutdown-at-night
skiboot
snapd
sosreport
system-tools-backends
systemd
sysvinit
toybox
tripwire
typespeed
u-boot
ukui-control-center
user-mode-linux-doc
virt-p2v
watchdog
wvdial
xen
xen-tools
yadm
yuma123

Correct.
containing an irqtop implementation, so that despite the fulfilled
hard dependency the other package should be listed as "Suggested but
not installed package", too.

Then again, that will not trigger either if I would change the
dependency on irqtop-nf only and put util-linux-extra only into
Suggests. Hrm.

Still wonder if using "Depends: irqtop-nf" plus "Suggests:
util-linux-extra" instead of how I proposed it beforehand and how it's
currently in git.

Hmmm, I kinda see where the reasoning comes from, but it doesn't look
like being a proper solution to me so far.

Oh, and JFTR: I fully agree that the hwclock infrastructure should not
be "essential" but optional in the sense of that the admin has the
possibility to not install or uninstall it if the installation is e.g.
a VM, a container or a SBC without an hardware clock.

		Regards, Axel

Hello Axel,

I am quoting your mail to document what we decided in our call
today, below. Basically we went back to "use dpkg-divert":

* Axel Beckert <abe@debian.org> [220417 13:50]:

Thanks,
Chris