At some point between 0.9.9 and 0.9.10 we removed the printing of option names when a value doesn't have a default, but this means the config is littered with things like:
# This option sets the greater foo value.
with no actual option name printed out when there is no default.
This fixes it by always printing the option name in such a case, just with an empty value, e.g.:
# This option sets the greater foo value.
#big-foo=
This makes the [lokid]:rpc setting required, because we cannot actually start up in service node mode if it is missing. The debs, which do have a sensible default, replace the rpc setting in the generated config in postinst (and broke because the commented-out field was missing, because of the above).
Default and Required don't make sense together, so we now fail to compile if used together. Similarly for Required and Hidden. The test code had a bunch of places that did use them together anyway: the behaviour of Default+Required was to write the uncommented default value into the config file, but we decided a long time ago that empty configs was our default so supporting that doesn't make sense.
Three changes:
At some point between 0.9.9 and 0.9.10 we removed the printing of option names when a value doesn't have a default, but this means the config is littered with things like:
with no actual option name printed out when there is no default.
This fixes it by always printing the option name in such a case, just with an empty value, e.g.:
This makes the
[lokid]:rpcsetting required, because we cannot actually start up in service node mode if it is missing. The debs, which do have a sensible default, replace the rpc setting in the generated config in postinst (and broke because the commented-out field was missing, because of the above).Default and Required don't make sense together, so we now fail to compile if used together. Similarly for Required and Hidden. The test code had a bunch of places that did use them together anyway: the behaviour of Default+Required was to write the uncommented default value into the config file, but we decided a long time ago that empty configs was our default so supporting that doesn't make sense.