[systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

[Tom Gundersen]

On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 20.11.13 14:38, Tom Gundersen (teg at jklm.no) wrote:
>
>> Pass on the line on which a section was decleared to the parsers, so they
>> can distinguish between multiple sections (if they chose to). Currently
>> no parsers take advantage of this, but a follow-up patch will do that
>> to distinguish
>>
>> [Address]
>> Address=192.168.0.1/24
>> Label=one
>>
>> [Address]
>> Address=192.168.0.2/24
>> Label=two
>>
>> from
>>
>> [Address]
>> Address=192.168.0.1/24
>> Label=one
>> Address=192.168.0.2/24
>> Label=two
>
> I do like this solution better, but I can see Thomas' point. And the
> issue Thomas points out manifests itself in handling of .d/
> directories... If we want to support .d/ directories for these
> configuration files (do we?) then how can we extend the settings of a
> specific existing [Address] section?

My take was that we do not want to support .d/ directories, in which
case unnamed sections would be fine, right? (i.e., as long as we only
ever consider one file at a time). Essentially I think it would be ok
to just tell people to copy the .network file to /etc and edit it
there.

If, on the other hand, we do want to allow .d/ directories in the
future, I think I'd advocate allowing both named and unnamed sections
(where only the named ones can be overridden of course). Notice that
we already encounter a similar overriding issue with the plain
Address= and Gateway= entries from the [Network] section, which can
not be accessed individually from .d/ fragments (but possibly cleared
altogether, as we allow in similar situations elsewhere).

I guess the normal use-case would then be that .nework files created
by admins would mostly (only) use the unnamed sections, as it is
simpler/neater and won't be something you'd ever override, but stuff
shipped by packages could use the named sections where overriding
might possibly make sense.

> So I do prefer the "linear" version above, but I see a problem with
> it...
>
> Hmm, what other options do we have?
>
> We could number things:
>
> [Address.0]
> ...
>
> [Address.1]
> ...
>
> [Address.2]
> ...
>
> and so on. I kinda like that too, but numbers might suck as ids?

Yes, I guess for someone writing the .d/ fragment it is annoying to
have to remember the number. So for something we expect could be
overridden, descriptive names would be best.

> Maybe then back to labelled sections:
>
> [Address:foobar]
> Label=waldo
> Address=1.1.1.1
>
> or so, so that the suffix "foobar" is purely an id that is by default
> disconnected from any setting? And then maybe optionally inherit it into
> Label= if Label= is not explicitly set?

I think the section name should not have any other function/meaning. I
first tried to make 'section name'='Label', but I'm worried it might
be confusing: If section names are required, it means we now require
labeling, or force the admin to set "Label=" to disable it, which
seems a bit weird. Also, I find it asymmetric the way section names
for Addresses have this extra meaning, but for Routes or other types
of sections where there is no natural equivalent to Label=, they have
no meaning apart from a name.

I'm really not convinced one way or the other, but I think my
preferred solution is: go with unnamed sections now, and if ever it
becomes necessary, introduce named ones additionally.

If we end up adding named sections, I do see the possible confusion of
"oh, I have to name these before I can override them...?". But if we
force always to name them I see people using 'random' strings "foo",
"bar", "baz", "rtyrty", "tryytr",.... and at some point getting lost
in what strings they have used and accidentally reusing strings (of
course the clever person would in this case name the sections "1",
"2", "3", etc). Basically, my concern is that there is not a big step
from requiring the user to invent unique strings to requiring
UUID's...

-t