Hello, About a month ago (so I hope I remember all the details correctly) I got motivated to revisit looking into this issue again.
My previous concern had been about how much work it would need because of how widely used pidof is. While actually looking closer at the users of pidof (using codesearch.debian.net to search for 'pidof ') I found that most callers where actually using 'if pidof ... ; then .... ; fi' and very few where calling pidof in a way that would actually fail if the command where not around. I also noticed that generally the (non-existant) "else" case where to be considered the correct code path for pidof not being installed in my opinion. The amount of packages actually needing pidof to be around thus was much lower than I first anticipated. Given that codesearch.debian.net would give source-code matches which could very well not be shipped at all in the resulting binary packages built from the source, I figured I'd set out to do some quick testing instead. I tried both 'debootstrap --variant=minbase' as well as a regular 'debootstrap' (including priority standard,important,required packages) both with the --exclude=sysvinit-utils. Both worked as a charm and as I see it proves that in theory the package being 'Essential: yes' is plain wrong. Additionally I tried booting (using systemd-nspawn) the regular chroot (with standard/important packages included) and could not spot anything problematic despite missing sysvinit-utils package. That probably points to the 'Priority: required' also being theoretically wrong. As I see it a possible plan for moving this forward could be to start off by dropping 'Essential: yes' (while still keeping 'Priority: required'). This would mean sysvinit-utils where still installed virtually everywhere (including 'debootstrap --variant=minbase'), while opening up for allowing packages to declare a dependency on sysvinit-utils where needed (without violating policy). (I bet someone will argue that this causes a theoretical correctness problem as some packages that should have a dependency lacks it. I would however like to point out that it's a theoretical problem, not a practical one as every installation will still have sysvinit-utils installed. I'd also like to point out that the current state of things already violates theoretical correctness as pointed out above. There's thus no theoretical regression, just one theoretical problem replaced with another - allowing to move forward and actually solving the theoretical issues.) This leads up to me wishing that people should tread carefully when introducing dependencies on sysvinit-utils, mainly as I think long-term we should switch to the procps implementation of pidof. Please urge anyone adding a dependency on sysvinit-utils not to just document they did so, but to clearly write down *why*. I haven't spend enough thought on if it would be simpler to move pidof from sysvinit-utils to procps at the same time or at a separate time. I know from personal experience that getting maintainers to drop pointless (build-)dependencies they've introduced in the past is close to impossible, even when you prove it's not needed (and even when the dep is on something that's going to get removed from the archive!). I think most uses of pidof can and should likely be fixed up instead of adding a dependency. For init scripts there's pidofproc in LSB for example. Likely you could go even deeper and question why using that is needed. You can likely get rid of that as well with a bigger refactoring/modernization of the init script. Once pidof is moved into procps, sysvinit should "obviously" gain a transitional dependency on procps. This however would make a 'Priority: required' package depend on a 'Priority: important' one (while no longer being a policy violation in itself, I think it's still suboptimal to make procps pseudo-required). This could be one reason why it would be better to postpone transitioning pidof until we're ready to consider downgrading sysvinit-utils to 'Priority: important' (or lower). (If anyone has concerns about the pidof implementations possibly not being 100% compatible, I'd just like to say that any such problem is already a portability problem as anything that only works with the sysvinit-utils pidof will not work on non-Debian distributions as basically everyone is already using procps pidof. It should thus in my opinion be fixed up in the caller.) Regards, Andreas Henriksson
