[abergeron]

This fixes a problem I had with avahi (service script is avahi-daemon but the variable is avahi_daemon) which led to the code trying to add a avahi-daemon_enabled="YES" line in /etc/rc.conf.local which is a syntax error.

Rather than trying to guess what the correct variable name is, I just use service enable/disable to make the edits, similar to what is done for OpenBSD.

• Pull request is based on the default branch (3.x at this time)
• Pull request includes tests for any new/updated operations/facts
• Pull request includes documentation for any new/updated operations/facts
• Tests pass (see scripts/dev-test.sh)
• Type checking & code style passes (see scripts/dev-lint.sh)
• Pull request title follows the
  conventional commits format

[wowi42]

Thanks for this one, the avahi-daemon rcvar mismatch is a nice catch and service <name> enable is clearly the right tool for it.

I went through the FreeBSD paths in detail: the new ServiceEnabled fact does its job, the service name is properly quoted everywhere, and I like that the two old JSON fixtures now use NetBSD so the rc.conf.local fallback keeps its coverage instead of silently losing it. Also good that existing rc.conf.local entries keep working, so nobody gets a surprise on upgrade.

Ran the bsdinit fixtures against your branch locally, all 18 pass, and CI is green too.

Two tiny nits, neither blocking:

• The prefix strip in ServiceEnabled.process only handles the two standard locations, so a service living in a custom local_startup dir would keep its full path as key and trigger a spurious re-enable. Harmless in practice since service enable is idempotent anyway.
• The new fact is a plain FactBase without a type parameter, same as its neighbours in the file, so consistent as-is.

[abergeron]

I should have fixed the two nits.