also: icmp6?

There are a bunch of routing daemons that can be used: frr, quagga, bird, openbgp, ...etc

I guess we should depend on the "dynamicrouting" (if the daemons above are consistent about PROVIDE in their rc.d files).

That was the exact reason to not touch it. It would be either to long or incomprehensible.

They are third party ports. The setting here is to deal with the base system primary. There might be a better solution, but I'm not in the position to overlook all the consequences and future developments.

No one uses routed. In the current form this change is useless.

So let's drop the idea completely, because there is no common pattern available?
Let's instead patch all the ports separately?

The various ports depend on "routing" but that's all they have in common.

Well, one can check for "bird frr quagga .." in PROVIDES as a hack.
However, I think it wouldn't be hard to update the most popular ports with relevant "provides" such as routing/dynamicrouting.

@olivier: what do you think?

Yes I can fix all routing ports to be sure they all PROVIDE the dynamicrouting keyword.

Okay, so I'll depend on this keyword for "auto", too. Will take some time to understand how it can be done at the correct time.

Can we just change this to "NO" ?

We can do this, if rc.d/routed would provide "dynamicrouting".
So you propose to set it to "no" and simultanously change routed?
(I'd like to understand before generating a new patch)

I propose removing anything related to routed.

Please keep this outside of this patch.
Add another patch to remove routed, there you can replace "$routed_enable" by "no".
So I'll not change this patch here.

Let me try to rephrase it. There is nothing specific about routed - technically it's one of the routing daemons, same as bird, frr or quagga. There should be no specific case handling it in rc.d/routing.

If you want, you can add the relevant PROVIDE to the etc/rc.d/routed in the same review.

Thank you for the idea of grepping before evaluating.

The >eval "$(grep rcvar $file)"< part should handle all the "set_rcvar" issues, you mentioned. This part was taken from /usr/sbin/service -e

I do not want to overwrite a configuration variable. To me this is bad practice. We do not know, if somebody will rely on this variable later on in a third party package.

Trying to handle all cases explicitly would require to duplicate the checkyesno code from rc.subr (i.e. for the debugging output). That's path I'd like to avoid.

But you are right, I updated the patch to avoid environment pollution.

No, please do not try to parse scripts by using grep. It is quite fragile. service(8) is broken in this regard, too.

"set_rcvar foo_enable YES" is another way to define foo_enable while it was not populated well. And name= and rcvar= can appear multiple times in a single script as in rc.d/sendmail and there is a plan to extend it to support multiple profiles which can have multiple rcvar= lines. So a handcrafted routine to extract foo_enable by parsing in rc.d/routnig is unnecessarily complex and harmful for future maintenance.

Why just calling the listed scripts with "enabled" argument is not enough? Calling load_rc_config_var() is so heavy and has substantially the same load as calling the script itself with "enabled".

I'm lost. What's your proposal to determine the existence of an enabled service providing a special tag (dynamicrouting)?

If there is no workable solution, I'll just modify the man page the clarify the usage of "yes"/"no".

I have kept saying the same proposal:

Invoking "rc.d/foo enabled" is the only way to get value of $foo_enable reliably.

Why just calling the listed scripts with "enabled" argument is not enough?

Again, please use calls of the scripts listed by grep with "enabled" instead of parsing them. More specifically, replacing l.306 to l.317 with the following should work for your purpose:

for file in $( rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null |
    xargs grep -lE '^# PROVIDE:.*\<dynamicrouting\>' ); do
        (set -- enabled; . $file) && return 0
done