Rudi, does fillup somwhoe remove extra variables that are not defined in the template?

it's not about extra variables, it's about using lowercase in the
variable names. AFAIR no one ever used lowercase in sysconfig variable
names

so is using lower case names forbidden by the specification or should fillup be fixed?

I'm not the fillup maintainer (any more)
the fix with the smaller impact would be to change it to an all uppercase
variable name

yet the question remains. NEEDINFO from new maintainer.

It seems to me, there is not lower/uppercase problem.

testcase.old
VARIABLE_lower="value3"
VARIABLE_UPPER="value4"
VARIABLE_lower2="value5"
VARIABLE_UPPER2="value6"

testcase.new
#VARIABLE_lower="value1"
#VARIABLE_UPPER="value2"

> fillup -m testcase.old testcase.new testcase.merged

testcase.merged
VARIABLE_lower2="value5"
VARIABLE_UPPER2="value6"

Rudi, if I understand correctly what fillup should do, contents of testcase.old and testcase.merged should be the same, or?

hm, if that bug is true it should be reproducable without upper/lowercase

old:
FOO="bar"
FOO2="bar2

new:
#FOO="bar2"

merged:
FOO2="bar2"

yes, a bug indeed.

So assign to me to see where is the problem.

To me I said :).

First problem I have met follows: for example block

----8<----------------------------------------------

## Type:        list(yes,no,int,ext,dmz,)
## Default:     no
#
# 23.)
# Specifies whether routing between interfaces of the same zone should be allowed
# Requires: FW_ROUTE="yes"
#
# Set this to allow routing between interfaces in the same zone,
# e.g. between all internet interfaces, or all internal network
# interfaces.
#
# Caution: Keep in mind that "yes" affects all zones. ie even if you
# need inter-zone routing only in the internal zone setting this
# parameter to "yes" would allow routing between all external
# interfaces as well. It's better to use
# FW_ALLOW_CLASS_ROUTING="int" in this case.
#
# Choice: "yes", "no", or space separate list of zone names
#
# Defaults to "no" if not set
#
FW_ALLOW_CLASS_ROUTING=""
---->8-----------------------------------------------

isn't interpreted as one CompleteVariableBlock, but as two blocks, 
- one CommentedVariableBlock 
    ("\n## Type: ... # FW_ALLOW_CLASS_ROUTING="int" in this case.") and 
- one CompleteVariableBlock 
    ("#\n# Choice: ... FW_ALLOW_CLASS_ROUTING="""). 

It turns out, that this case is actually not a problem, because FW_ALLOW_CLASS_ROUTING occurs once commented and once uncommented.

But, think of _old_ file
-------------------------------------
#   FW_ALLOW_FW_BROADCAST_wlan="yes"
#
FW_ZONES=""
FW_ALLOW_FW_BROADCAST_wlan="yes"

and _new_ file
--------------------------------------
#   FW_ALLOW_FW_BROADCAST_wlan="yes"
#
FW_ZONES=""

then _merged_ file by fillup -m is (in virtue of the fillup code)
---------------------------------------
#
FW_ZONES=""

(Note, without comment as well.) If I understand the code correctly yet, the output of fillup -m is always the following:

old              new            merged
FOO=val-old      FOO=val-new    FOO=val-old
#FOO=val-old     FOO=val-new    FOO=val-new
FOO=val-old      #FOO=val-new   ---
#FOO=val-old     #FOO=val-new   ---

Q1: Why are commented variables handled at all? 
Q2: Is behaviour in previous table right?
Q3: Behaviour explained in first example is definitely wrong, but fix fillup
    seems to be out of scope of 11.1, no?

On my system are affected:
/etc/sysconfig/SuSEfirewall2
/etc/sysconfig/network/ifcfg.template
/etc/sysconfig/postfix
/etc/sysconfig/autofs
/etc/sysconfig/displaymanager

Q1: commented variables are just that.
they should be retained in the file since they are either examples from us
or alternative/previous settings the admin left in this place for a purpose.
They have nothing at all to do with the active setting of the variable
(or even the removal of that one), that is a bug.

Q2: no, I think that is buggy.

Q3: fixing fillup would be desirable, but having this in 11.1 is pretty late.
Do you have any estimate on how long it would take to fix this ?

Q1 was meaned another way: I wonder why chunk

#
# commented block without any FOO1=value1 directly after #
#
#FOO=value

get special "CommentedVariableBlock" type. I guess^2 that it could be the "example" as you said. I have some scrappy informations that in the past was only one variable per one chunk allowed (not true now, see /etc/sysconfig/joystick). If yes, then table above begins to have little sense (above all, I don't understand the third line while -m is used -- this is actually our problem). 

There is much of code to handle commented variable blocks, therefore I don't believe it hasn't or hadn't some purpose. Unfortunatelly, I haven't find any document that describes intended fillup behaviour by now. Thus, I cannot say how long it can take to fix it, because I don't actually know what to fix :-). But for 11.1 is too late anyway (I am new for fillup, you know), I agree.

There is an easy wrokaround to fix this:

# Examples: "tr0", "eth0 eth1"

or

# Example:
# * FW_ZONES="wlan"
# * FW_DEV_wlan="wlan0"
# * FW_SERVICES_wlan_TCP="80"
# * FW_ALLOW_FW_BROADCAST_wlan="yes"
#

By the way, wasn't somewhere usage or recommendation to not use #FOO=value in the real comment?

Because I don't see any other way I propose to simply drop support for commented variable blocks in fillup: 

Every sysconfig file/template should contain only

--------------------------------------------------------
##
##  metadata block 1
##
#
# help block 1 -- with or without lines like # FOO=VALUE
#
FOO11=VALUE11  variable asignment block 1 *without* # FOO=VALUE,  
...            simply because # has a special meaning; 
FOO1N=VALUE1N  variable can be set empty by VARIABLE=

##
##  metadata block 2
...
...
...
FOOMN=VALUEMN  variable block M
--------------------------------------------------------

Further, I think deletion of variables should be prohibited or documented (if it's not yet) too, because

## Type:        yesno
## Default:     yes
#
# help 1
# deleted FOO="value" from here

## Default:     no
#
# help 2
#
BAR="no"

will 
- break yast2 sysconfig help; whole block above BAR="no" will be taken
  as comment to BAR. Fortunately metadata are interpreted right way.
- lead to use FOO="new-value" from new sysconfig file during update. Merged file can then look like

## Type:        yesno
## Default:     yes
#
# new help 1
FOO="new-value"

## Type:        yesno
## Default:     yes
#
# help 1
# deleted FOO="value" from here

## Default:     no
#
# help 2
#
BAR="no"

(So something not expected by user I guess.)

What do you think about it?

the only case where variables should be removed at all is
if the "-r" option is used as far as I can tell.

fillup -q -t -r -i -d "=" foo removelist /dev/null
test -f foo.new && mv foo.new foo


actually I know exactly two uses of fillup:
            bin/fillup -q etc/sysconfig/$SD_NAME$PNAME $SYSC_TEMPLATE \
(default case, 95% of all cases)

        bin/fillup -q -t -r -i -d "=" etc/sysconfig/$PNAME $DEL_TEMPL etc/sysconfig/$PNAME.deleted.$$ \
(remove case, the rest of occurences)

and only the second one should really remove things.

Does this answer the question ?

Reassigning to mhrusecky, the new maintainer of fillup.