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