<div dir="ltr"><div>I prefer this way myself. Also if people really want sysvinit pidof its still there; e.g if procps pidof breaks some obscure thing horribly, they're one update-alternative away from health.</div><div><br></div><div> - Craig</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 5 May 2026 at 17:34, Andrew Bower <<a href="mailto:andrew@bower.uk">andrew@bower.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sub-thread aimed at easing and accelerating the transition:<br>
<br>
On Mon, Apr 27, 2026 at 10:47:55PM +0200, Gioele Barabucci wrote:<br>
> 4. Inside a single dinstall window, a modified version of `sysvinit-tools`<br>
> (without `pidof`) and a modified version of `procps` (with `pidof`) will be<br>
> uploaded. (WIP patches can be found at [4] and [5].)<br>
<br>
Symlinks are cheap and dh_installalternatives is easy to use.<br>
<br>
How about bringing a modified version of step 4 forward to steps 0a and<br>
0b?<br>
<br>
0a) We could immediately upload sysvinit-utils with pidof renamed to<br>
    /usr/bin/pidof.sysvinit with an alternative of priority 40.<br>
<br>
0b) Then we could upload procps with pidof provided as<br>
    /usr/bin/pidof.procps with an alternative of priority 80 and an<br>
    appropriate versioned Breaks clause.<br>
<br>
Then we could more quickly smoke out possible issues and make it easier<br>
for people to play with both tools in parallel.<br>
</blockquote></div>