always check/reject all deprecated/removed env variable

[fujitatomoya]

Generated by Generative AI

No response

Operating System:

5.15.0-139-generic #149~20.04.1-Ubuntu SMP Wed Apr 16 08:29:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

ROS version or commit hash:

rolling, kilted, jazzy and humble

RMW implementation (if applicable):

No response

RMW Configuration (if applicable):

No response

Client library (if applicable):

No response

'ros2 doctor --report' output

ros2 doctor --report

<COPY OUTPUT HERE>

Steps to reproduce issue

1. use ROS_LOCALHOST_ONLY env variable with humble.
2. migrate the application to jazzy (or kilted, across more than 2 upstream distribution) with ROS_LOCALHOST_ONLY.
3. ROS_LOCALHOST_ONLY is not effective any more without any warnings or error messages.

Expected behavior

Deprecated or removed environmental variables should give either warning or error to block the application at runtime, so that user can know that the environmental variable is not effective anymore and how it needs to be replaced.

The usual deprecation period is given for at least one distribution such as API deprecation.
for example, some API is supported in humble, that is deprecated with warning message in iron, and it is removed completely in jazzy. this is no problem for API deprecation procedure since user application can realize the build failure because of the removal in jazzy.
But this becomes the problem once it comes to environmental variable like ROS_LOCALHOST_ONLY.
ROS_LOCALHOST_ONLY has been deprecated in Iron (replaced with Improved Dynamic Discovery), and removed in Jazzy.
That said, if we use Jazzy or Kilted with ROS_LOCALHOST_ONLY env variable, it will not say any warnings or error detected at runtime. it just stays silent and the env variable is not effective, that is not good behavior for user experience.

Actual behavior

Even after the removal of environmental variable, it should be still able to let the user know that this environmental variable is NOT effective anymore with warning and error message. So that user will be able to know that their configuration is not effective anymore when they upgrade the distribution especially across more than 2 upstream distributions.

Additional information

The original discussion came up in #1238.

Implementation Consideration:

probably we can have deprecated/removal environmental variable list in low level implementation somewhere rcl packages, and check the env variable setting in the process space via rcl_init during context initialization, then warn or error the application at runtime.
possibly construct the rcl API to handle those checking and accessing list for the clients libraries, so that ros2doctor can also detect the invalidate environmental variables are configured in the shell.