Hi, sorry, for some reason I did not received you reply..
On Sat, 31 Jan 2026 18:28:41 +0000 "S. Osipiuk" <[email protected]> wrote: > > if [ -f /etc/runit/override-sysv.d/"$name".sysv ]; then > > ^ As I understand it, dep-fixer is specifically for dbus-dependent > services, so it should not be starting other services, even with an > override. I think the override logic should do the .depend.start > check also. I overlooked this, will have a look again and adjust for the next upload; thanks for following up. > > Also, what is the rationale for scanning /usr/share/runit/sv.current/ > but not /usr/share/runit/sv/? well this is not straightforward to understand but roughly: /usr/share/runit/sv/: contains the full stash of services shipped by runit-services (included ones that are not relevant for the system because the correspondent binary/package is not installed) /usr/share/runit/sv.current/ contains a subset of usr/share/runit/sv/, specifically it contains only the services that can be run on the system because the correspondent binary is installed in the system (the .meta/bin file in each service dir is used for this). (there are also other differences, but not relevant for this bug) So I think scanning /usr/share/runit/sv.current/ is enough. >I thought the latter was in the same > category as /etc/sv/ (services known/defined but not enabled) which > does get checked, since the logic is that if a user has a runit > service available but isn't using it, then presumably they don't want > the sysv version either (unless overridden). I agree with that logic, > but I'm not 100% clear on the purpose of each directory. > > >
