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