Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[zhenwei pi]

Package: util-linux
Version: 2.36.1-7
Severity: wishlist

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.

-- System Information:
Debian Release: 11.0
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.0-39-generic (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages util-linux depends on:
ii libaudit1 1:3.0-2
ii libblkid1 2.36.1-7
ii libc6 2.31-12
ii libcap-ng0 0.7.9-2.2+b1
ii libcrypt1 1:4.4.18-4
ii libmount1 2.36.1-7
ii libpam0g 1.4.0-7
ii libselinux1 3.1-3
ii libsmartcols1 2.36.1-7
ii libsystemd0 247.3-5
ii libtinfo6 6.2+20201114-2
ii libudev1 247.3-5
ii libuuid1 2.36.1-7
ii login 1:4.8.1-1
ii zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn dosfstools <none>
pn kbd <none>
pn util-linux-locales <none>

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "zh_CN.UTF-8",
LC_MONETARY = "zh_CN.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_ADDRESS = "zh_CN.UTF-8",
LC_TELEPHONE = "zh_CN.UTF-8",
LC_NAME = "zh_CN.UTF-8",
LC_MEASUREMENT = "zh_CN.UTF-8",
LC_IDENTIFICATION = "zh_CN.UTF-8",
LC_NUMERIC = "zh_CN.UTF-8",
LC_PAPER = "zh_CN.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

[Chris Hofstaedtler]

Hi zhenwei pi,

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

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

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

[zhenwei pi]

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!

--
zhenwei pi

[Axel Beckert]

Hi Chris, hi zhenwei,

Chris Hofstaedtler wrote:
> > 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.
>

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

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

[Chris Hofstaedtler]

Hi Axel, zhenwei,

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

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

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?

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

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


Thanks,
Chris

[zhenwei pi]

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

--
zhenwei pi

[Axel Beckert]

Hi Chris,

Chris Hofstaedtler wrote:
> > 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.
>
> Right. I think I forgot to reply back then - sorry.

Happens…

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

Thanks. That package though seems to miss the "Conflicts: irqtop". :-/
But I was aware of it and uninstalled irqtop beforehand. :-)

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

Hmmmm.

> In any case we should not confuse our users.

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.

> > 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.
>
> Might be an idea. But lets see what the differences are, first.

Ack.

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

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

> Test env: Debian 10; 96 CPUs on a server, 230 characters per line in
> termial.
>
> - irqtop (original version) shows uncompleted interrupts(31 / 96 CPUs).

Hrm, interesting.

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

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

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

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

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

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

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.

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

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.

[Chris Hofstaedtler]

Hi Axel,

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

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

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

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

Right.

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

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

[Axel Beckert]

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:
> > 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.)
>
> (I understand this is "temporarily fixed" now.)

Indeed. I was very surprised and happy that my poking of the (not-)
maintainers actually triggered an upload. :-)

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

The sole thing we get off this is that users who have used the
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.
:-)

> Regardless of using u-a, (I think) util-linux would need to grow a
> versioned Conflicts/Replaces/Breaks on irqtop.

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

> 2) If we settle on update-alternatives, irqtop from util-linux
> really needs to be (and stay) in util-linux-extra.

I thought that was your plan anyways.

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

I see.

> All of this pretty much already says util-linux-extra should have
> irqtop, and not util-linux.

Ack.

> So, if we go with update-alternatives, which program names do you
> propose? irqtop-nf and irqtop-ul?

Yes.

> There is some precedent to use "." instead of "-", but probably
> either are fine.

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:

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

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!

[Chris Hofstaedtler]

Hi Axel,

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

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

Thanks for the analysis and suggestions!

> [..]

> * 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'd be happy if you could fix the missing Breaks/Replaces headers in
> util-linux-extra. TIA!

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

[Axel Beckert]

Hi Chris,

> > * 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'd be happy if you could fix the missing Breaks/Replaces headers in
> > util-linux-extra. TIA!
>
> Both - the Breaks/Replaces, and the package description - are now in
> experimental, as src:util-linux / util-linux-extra 2.38-4+exp2.

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.

> Would love your feedback on these changes.

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.

[Chris Hofstaedtler]

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

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

Yes, that sounds better. Will do, thanks.

> 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.
>
> > Would love your feedback on these changes.
>
> 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?

This is for transitional reasons: hwclock (and some other less
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

[Axel Beckert]

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:
> > Why does util-linux have a hard dependency on util-linux-extra?
>
> This is for transitional reasons: hwclock (and some other less
> important bits) got moved to -extra.

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

> I want to avoid surprises for users that still need hwclock.

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.

> After bookworm I'll replace Depends with Suggests/Recommends.

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

> Technically the Depends from irqtop to util-linux-extra is not
> needed.

Correct.

> I think it still makes sense to have it, in case the relations
> between util-linux and util-linux-extra change before the release.

Hmm, I've also (yesterday) added a Suggests on both packages
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.

> Do you agree?

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.

[Chris Hofstaedtler]

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 <a...@debian.org> [220417 13:50]:

Thanks,
Chris