Bug#851747: sysvinit-utils: drop Essential flag
FYI I've filed https://bugs.debian.org/954306 to track the potential adjustment of the Priority: field, which seems to be the majority of the discussion in this bug report. I'm about to upload an NMU of sysvinit which drops the 'Essential: yes' from sysvinit-utils - but still keeps 'Priority: required' unchanged (and closing this bug report while doing so) for now. Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
On Sat, Feb 08, 2020 at 07:23:32PM +0100, Andreas Henriksson wrote:
> Hello,
>
> Regarding the previous discussion about packages with init scripts
> that source /lib/init/vars.sh
[...]
As a followup on this I've now also (re)checked all users of
init-d-script for the current status. (I consider both the vars.sh and
init-d-script usage issues mostly relevant to potentially adjusting
Priority of sysvinit-utils package, rather than being Essential: yes.)
TL;DR very few relevant packages, specially if only considering ones
relevant for bullseye/testing.
Method:
I used codesearch.debian.net searching for init-d-script
and got 73 total source packages matching.
I excluded src:sysvinit and src:systemd as they should not be relevant
for this examination, so 71 source packages remaining.
I downloaded all those source packages, checked their debian/control
for binary packages and downloaded those from unstable.
I then examined the binary packages for existance of etc/init.d/*
content and checked if etc/init.d/foo has a matching
systemd/system/foo.service.
Here's my annotated results for the ones that did not have
a masking systemd service (according to my naive search):
=== axfrdns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
axfrdns
=== bcron_0.11-8_amd64.deb.txt
bcron-sched
bcron-spool
bcron-update
=== courier-imap_5.0.6+1.0.6-1+b2_amd64.deb.txt
courier-imap-ssl
=== courier-mta_1.0.6-1+b2_amd64.deb.txt
courier
courier-msa
courier-mta-ssl
courierfilter
=== courier-pop_1.0.6-1+b2_amd64.deb.txt
courier-pop-ssl
=== dnscache_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
dnscache
=== jitterentropy-rngd_1.1.0-1_amd64.deb.txt
# NOTE: false-positive -- jittenentropy.service has Also=
jitterentropy-rngd
=== mtail_3.0.0~rc24.1-1_amd64.deb.txt
# See #886894
mtail
=== netplan_1.10.1-6_amd64.deb.txt
# NOTE: not in testing, orphaned
netplan
=== opentmpfiles_0.2+2019.05.21.git.44a55796ba-2_all.deb.txt
# NOTE: Not relevant for systemd (and others?)?
opentmpfiles-clean
opentmpfiles-setup
opentmpfiles-setup-dev
=== procps_2%3a3.3.16-4_amd64.deb.txt
# NOTE: false-positive -- actually masked
procps
=== rbldns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
rbldns
=== shishi-kdc_1.0.2-7_amd64.deb.txt
shishi-kdc
=== tinydns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
tinydns
=== uwsgi-emperor_2.0.18-8_amd64.deb.txt
uwsgi-emperor
=== uwsgi_2.0.18-8_amd64.deb.txt
# See #833067
uwsgi
=== walldns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
walldns
Relevant popcon link:
https://qa.debian.org/popcon-graph.php?packages=shishi-kdc%2Cbcron%2Ccourier-imap%2Ccourier-mta%2Ccourier-pop%2Cjitterentropy-rngd%2Cmtail%2Cuwsgi-emperor%2Cuwsgi%2Copentmpfiles&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
(Relevant packages according to popcon: courier-{imap,pop} and uwsgi)
Regards,
Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
‐‐‐ Original Message ‐‐‐ On Saturday, February 8, 2020 6:23 PM, Andreas Henriksson wrote: > Hello, > [...] > https://bugs.debian.org/950696 > [...] Hello, just an observation about #950696: there is git-daemon-run (runit runscript) and git-daemon-sysvinit (sysvinit script), so the maintainer probably expect you to add a separate 'git-daemon-systemd' package. Alternatively you can propose the maintainer to merge all inits support in one 'git-daemon' package. Regards, Lorenzo
Bug#851747: sysvinit-utils: drop Essential flag
Am 08.02.20 um 19:23 schrieb Andreas Henriksson: > Hello, > > Regarding the previous discussion about packages with init scripts > that source /lib/init/vars.sh > > I've now submitted bug reports including an attempt at a service file > for packages with popcon install count above 100 (and some below), Thanks so much for your work, Andreas. Very much appreciated! Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#851747: sysvinit-utils: drop Essential flag
Hello, Regarding the previous discussion about packages with init scripts that source /lib/init/vars.sh I've now submitted bug reports including an attempt at a service file for packages with popcon install count above 100 (and some below), except for a few that I didn't find motivation for: sasl2-bin sendmail-bin xen-utils-common lprng webfs heimdal-kcm The bug reports in question are: https://bugs.debian.org/950236 https://bugs.debian.org/950240 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738548 https://bugs.debian.org/950427 https://bugs.debian.org/950241 http://bugs.debian.org/950952 https://bugs.debian.org/950432 https://bugs.debian.org/950694 https://bugs.debian.org/950246 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950263 https://bugs.debian.org/950696 https://bugs.debian.org/950697 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849955 https://bugs.debian.org/950270 http://bugs.debian.org/950948 https://bugs.debian.org/950949 https://bugs.debian.org/950945 https://bugs.debian.org/950943 https://bugs.debian.org/950951 https://bugs.debian.org/950442 https://bugs.debian.org/950320 https://bugs.debian.org/793854 https://bugs.debian.org/950441 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833067 https://bugs.debian.org/950388 https://bugs.debian.org/950386 My impression is that adding service files for most of the affected init scripts should be pretty straight forward and hasn't been done simply because the maintainer hasn't cared enough to do so. In case there are any complex cases those could ofcourse always resort to depending on sysvinit-utils. Several of the init scripts I've looked at already use commands and assume packages with Priority >= important are always installed and don't specify dependencies for them (and it'll likely be quite a while before sysvinit-utils drops its priority below that, which is certainly not the scope for this bug report). Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
On Fri, 31 Jan 2020, Andreas Henriksson wrote: > > One of mine popped up, and, while I might investigate into > > writing a systemd service for it, > > In my opinion it's just time (well overdue if you ask me) that > /everything/ gets native systemd units. The sysvinit compatibility is > just a compatibility shim. It doesn't give you many of the advantages of > systemd that someone using systemd would expect. Yesss, but I cannot test them, and I don’t know about the specifics. > I don't think that's needed as vars.sh (and sysvinit-utils) is > (and likely always will be) guaranteed to be installed on a > sysvinit(-core) system. Wasn’t this thread about the issue of what to do with them on a non-sysvinit system that uses initscript fallback (and there are multiple of those)? > Given that exists, it's not possible for lsb-base to depend on > sysvinit-utils as it would cause a circular dependency. Yeah… except if you split the scripts into another package. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#851747: sysvinit-utils: drop Essential flag
Hello Thorsten Glaser, On Thu, Jan 30, 2020 at 07:17:49PM +0100, Thorsten Glaser wrote: > On Thu, 30 Jan 2020, Andreas Henriksson wrote: > > > the binary packages built from it where downloaded, checked if it > > had any init script, if it used vars.sh, and if there was a service > > One of mine popped up, and, while I might investigate into > writing a systemd service for it, In my opinion it's just time (well overdue if you ask me) that /everything/ gets native systemd units. The sysvinit compatibility is just a compatibility shim. It doesn't give you many of the advantages of systemd that someone using systemd would expect. As a "side effect" we also happen to get looser coupling that benefits this case. (Also feel free to ask for help mentioning which package it is.) > I wonder: the use of vars.sh goes along with use of > /lib/lsb/init-functions (which lintian tells users to add a dependency > on lsb-base for). > > Would it be absurd to let lsb-base pull in vars.sh? I don't think that's needed as vars.sh (and sysvinit-utils) is (and likely always will be) guaranteed to be installed on a sysvinit(-core) system. The sysvinit-core, sysv-rc, initscripts packages all declare dependency on sysvinit-utils already (despite sysvinit-utils being Essential: yes). And IMHO atleast one of those should stay (after Essential: yes has been dropped). > > If we did that, would most of these be fixed, or just a > small amount? I want less coupling, not more... and on that subject I recently filed a bug about sysvinit-utils gaining a dependency on lsb-base (making it pseudo-essential). Given that exists, it's not possible for lsb-base to depend on sysvinit-utils as it would cause a circular dependency. Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
On Thu, 30 Jan 2020, Andreas Henriksson wrote: > the binary packages built from it where downloaded, checked if it > had any init script, if it used vars.sh, and if there was a service One of mine popped up, and, while I might investigate into writing a systemd service for it, I wonder: the use of vars.sh goes along with use of /lib/lsb/init-functions (which lintian tells users to add a dependency on lsb-base for). Would it be absurd to let lsb-base pull in vars.sh? If we did that, would most of these be fixed, or just a small amount? Just wondering, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#851747: sysvinit-utils: drop Essential flag
On Tue, Jan 28, 2020 at 05:29:44PM +0100, Andreas Henriksson wrote: > Hi Michael, > > On Tue, Jan 28, 2020 at 04:38:36PM +0100, Michael Biebl wrote: [] > > /lib/init/vars.sh > > From random samples this seems exctusively used from init scripts (and > examples of init scripts), so I'd say a masking native systemd unit > would be my preferable fix (rather than a sysvinit-utils dependency). > > There are 280 codesearch hits. > > > > > Those are the more tricky ones. A lot of init scripts use them. > > Not having those installed will render the init scripts of packages > > broken. It's less of an issue, if a package ships a native service file. > > (Do we know for how many this is the case, i.e. no .service file, SysV > > init script using init-d-script and/or vars.sh?) > > (I just have to start by saying, dropping 'Essential: yes' doesn't mean > people will stop having sysvinit-utils installed. The literal definition > of 'Priority: required' is that your system will break if you remove > this package. I guess you're thinking ahead of potential future lowering > the priority) > > I haven't investigated how many of the init-d-script and vars.sh issues > are already solved. I'll however volunteer to look all of the affected > packages over (and hopefully submit patches for them) once the > 'Essential: yes' bit is dropped. > > (I'll *not* look them over before 'Essential: yes' is dropped, simply > because that's alot of work that will rot and will have to be redone > again and again and again. So just a waste of my time.) [...] So I couldn't resist and made a crude hack to try get some numbers. I wouldn't trust this to be the exact, but it should give a ballpark figure. For each of the 280 hits on codesearch.debian.net (source packages), the binary packages built from it where downloaded, checked if it had any init script, if it used vars.sh, and if there was a service with the same name masking it (NOTE: No checking if the service was invoking the init script where done!). The result where: * 95 source packages produce binary packages with init scripts that use vars.sh but has no matching service file. * 126 init scripts in total uses vars.sh without having a matching unit file. Please note that this does not account for any complex cases, it's just a crude hack after all. Please also note that some of these probably should not be fixed, eg. initscripts is an obvious example (or anything from src:sysvinit). There are also other packages that simply exists to fill a gap in the sysvinit world, like llmnrd, which is debatable. Full list below: No matching service for /etc/init.d/activemq in activemq (src:activemq) No matching service for /etc/init.d/ahcpd in ahcpd (src:ahcpd) No matching service for /etc/init.d/amavisd-snmp-subagent in amavisd-new (src:amavisd-new) No matching service for /etc/init.d/amavis-mc in amavisd-new (src:amavisd-new) No matching service for /etc/init.d/amule-daemon in amule-daemon (src:amule) No matching service for /etc/init.d/anope in anope (src:anope) No matching service for /etc/init.d/aprx in aprx (src:aprx) No matching service for /etc/init.d/babeld in babeld (src:babeld) No matching service for /etc/init.d/bareos-dir in bareos-director (src:bareos) No matching service for /etc/init.d/bareos-fd in bareos-filedaemon (src:bareos) No matching service for /etc/init.d/bareos-sd in bareos-storage (src:bareos) No matching service for /etc/init.d/calendarserver in calendarserver (src:calendarserver) No matching service for /etc/init.d/camo in camo (src:camo) No matching service for /etc/init.d/cfengine3 in cfengine3 (src:cfengine3) No matching service for /etc/init.d/charybdis in charybdis (src:charybdis) No matching service for /etc/init.d/c-icap in c-icap (src:c-icap) No matching service for /etc/init.d/citadel in citadel-server (src:citadel) No matching service for /etc/init.d/citadel in citadel-server (src:citadel) No matching service for /etc/init.d/consolation in consolation (src:consolation) No matching service for /etc/init.d/crtmpserver in crtmpserver (src:crtmpserver) No matching service for /etc/init.d/saslauthd in sasl2-bin (src:cyrus-sasl2) No matching service for /etc/init.d/ddclient in ddclient (src:ddclient) No matching service for /etc/init.d/diaspora in diaspora-common (src:diaspora-installer) No matching service for /etc/init.d/diod in diod (src:diod) No matching service for /etc/init.d/dnsproxy in dnsproxy (src:dnsproxy) No matching service for /etc/init.d/dtc-xen-firewall in dtc-xen-firewall (src:dtc-xen) No matching service for /etc/init.d/dtc-xen-firewall in dtc-xen-firewall (src:dtc-xen) No matching service for /etc/init.d/dump1090-mutability in dump1090-mutability (src:dump1090-mutability) No matching service for /etc/init.d/edac in edac-utils (src:edac-utils) No matching service for /etc/init.d/elog in elog (src:elog) No matching service for /etc/init.d/errbot in errbot (src:errbot) No matching service for /etc/init.d/fp-facilitator i
Bug#851747: sysvinit-utils: drop Essential flag
Am 28.01.2020 um 17:38 schrieb Andreas Henriksson: > On Tue, Jan 28, 2020 at 05:02:38PM +0100, Michael Biebl wrote: > [...] >> Assuming the .service isn't just a wrapper around the init script. >> Unfortunately, we do have quite a few packages which use this >> anti-pattern :-/ >> >> https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1 > > https://lintian.debian.org/tags/systemd-service-file-wraps-init-script.html Thanks for that pointer. Totally forgot that we had a lintian check for that. > It seems "Debian OpenStack" is the main offender so unless people use > openstack the problem possibly isn't that widely spread. Indeed. > This however serves as a good reminder that it's not enough to just > check that there's a masking native systemd unit. > (I'll probably forget about that very soon again, but atleast there's > now a note/warning about this case in this bugs history! :) > > (It might be time to ask lintian maintainers to consider raising > severity or turning some warnings into errors for systemd-related > lintian checks.) Sounds like a good idea. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#851747: sysvinit-utils: drop Essential flag
On Tue, Jan 28, 2020 at 05:02:38PM +0100, Michael Biebl wrote: [...] > Assuming the .service isn't just a wrapper around the init script. > Unfortunately, we do have quite a few packages which use this > anti-pattern :-/ > > https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1 https://lintian.debian.org/tags/systemd-service-file-wraps-init-script.html It seems "Debian OpenStack" is the main offender so unless people use openstack the problem possibly isn't that widely spread. This however serves as a good reminder that it's not enough to just check that there's a masking native systemd unit. (I'll probably forget about that very soon again, but atleast there's now a note/warning about this case in this bugs history! :) (It might be time to ask lintian maintainers to consider raising severity or turning some warnings into errors for systemd-related lintian checks.) Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
Hi Michael, On Tue, Jan 28, 2020 at 04:38:36PM +0100, Michael Biebl wrote: > Hi Andreas, > > thanks for your interest in this topic. Thanks for your interest in my interest. :) Always nice with some feedback. > > Aside from /bin/pidof, we also have ... a bunch of niche tools that has been discussed before. I haven't really looked at these recently but I guess not much has changed, except maybe init-d-script has gotten a bit wider usage. Will try to give some kind of updated status for these below... > > /sbin/fstab-decode Still only 2 users found by codesearch: drbl, open-iscsi > /sbin/killall5 Still very few users. The following codesearch hits seemed somewhat relevant to investigate: util-vserver, apcupsd, lxc-templates (likely not shipped), drbl, rear > > I haven't checked codesearch if those binaries are used outside of > sysvinit/initscripts. Have you investigated those recently? > > > And there is also > /lib/init/init-d-script In the past this had few users. These days I'd say the better fix than adding sysvinit-utils dependency is to just require users of init-d-script to also ship a masking native systemd unit. There are 73 total hits for init-d-script on codesearch (including false positives like lintian), so certainly still manageable. > /lib/init/vars.sh >From random samples this seems exctusively used from init scripts (and examples of init scripts), so I'd say a masking native systemd unit would be my preferable fix (rather than a sysvinit-utils dependency). There are 280 codesearch hits. > > Those are the more tricky ones. A lot of init scripts use them. > Not having those installed will render the init scripts of packages > broken. It's less of an issue, if a package ships a native service file. > (Do we know for how many this is the case, i.e. no .service file, SysV > init script using init-d-script and/or vars.sh?) (I just have to start by saying, dropping 'Essential: yes' doesn't mean people will stop having sysvinit-utils installed. The literal definition of 'Priority: required' is that your system will break if you remove this package. I guess you're thinking ahead of potential future lowering the priority) I haven't investigated how many of the init-d-script and vars.sh issues are already solved. I'll however volunteer to look all of the affected packages over (and hopefully submit patches for them) once the 'Essential: yes' bit is dropped. (I'll *not* look them over before 'Essential: yes' is dropped, simply because that's alot of work that will rot and will have to be redone again and again and again. So just a waste of my time.) > Also, we have /etc/init.d/foo → redirection to systemctl broken unless > /lib/lsb/init-functions is the first thing that is sourced. > Maybe that breakage is acceptable? Dunno. > What are your thoughts here? I think at as time goes by assuming people being used to init scripts rather than systemctl/service commands becomes less and less true. I might be to progressive but I'd say we're now at a point where it's not very important to keep shielding the users from mistakes like directly invoking an init script. While many oldtimers could likely spell out the full /etc/init.d/foo path of a number of important services in their sleep, I also think there's a whole generation of people around now that administer systems without knowing what /etc/init.d does at all. > > Given the size of the sysvinit-utils package, last time I looked into > this I concluded it's probably not worth the trouble. But maybe things > have changed by now. I agree with this, but the reason I'm here again is because I've managed to tick off most of the issues which had higher payoff already. It's this one and #833256 (where I'd make the new packages non-essential in the same go) left from my old investigations then there are the "legendary" ideas that is as insane/unrealistic amount of work like getting bash or perl out of the base. (But the value is not very high there either, so I'd say it's even less worth to work on that than this.) Then there's things that might really painful (if at all possible) but more rewarding, like shrinking the largest packages in the base system: e.g. coreutils. While size is one factor, I think getting rid of essential where not needed has value in that dependencies can actually be properly declared/tracked. For all the normal reasons in debian why being able to track the dependencies is good, there's also likely value in bootstrapping as well as more easily being able to build custom minimal systems. Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
Am 28.01.20 um 16:38 schrieb Michael Biebl: > And there is also > /lib/init/init-d-script > /lib/init/vars.sh > > Those are the more tricky ones. A lot of init scripts use them. > Not having those installed will render the init scripts of packages > broken. It's less of an issue, if a package ships a native service file. Assuming the .service isn't just a wrapper around the init script. Unfortunately, we do have quite a few packages which use this anti-pattern :-/ https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1 Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#851747: sysvinit-utils: drop Essential flag
Hi Andreas, thanks for your interest in this topic. Aside from /bin/pidof, we also have /sbin/fstab-decode /sbin/killall5 I haven't checked codesearch if those binaries are used outside of sysvinit/initscripts. Have you investigated those recently? And there is also /lib/init/init-d-script /lib/init/vars.sh Those are the more tricky ones. A lot of init scripts use them. Not having those installed will render the init scripts of packages broken. It's less of an issue, if a package ships a native service file. (Do we know for how many this is the case, i.e. no .service file, SysV init script using init-d-script and/or vars.sh?) Also, we have /etc/init.d/foo → redirection to systemctl broken unless /lib/lsb/init-functions is the first thing that is sourced. Maybe that breakage is acceptable? Dunno. What are your thoughts here? Given the size of the sysvinit-utils package, last time I looked into this I concluded it's probably not worth the trouble. But maybe things have changed by now. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#851747: sysvinit-utils: drop Essential flag
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
