First variant is ok. But the second is broken. I'll have a look...

OK, I think I know why it happens. I am just not sure yet what would be the
proper way to fix. We have:

! model         layout                          =       symbols
...
  $pcmodels     ben                     =       pc(%m)+in(ben)
  *             ben                     =       pc(pc105)+in(ben)
...

then

! layout[2]     =       symbols
...
  ben(probhat)  =       +in(ben_probhat):2
...

Both rules applied, we got this incorrect double entry...
Now I am thinking what would be the right solution.

Actually even this works ok:

$ setxkbmap -model pc105 -layout 'us,ben(probhat)' -option '' -print
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc(pc105)+us+in(ben_probhat):2"        };
        xkb_geometry  { include "pc(pc105)"     };
};

The problem arises when variant is put as a separate option. So the $100 is how
to fix it. With all fairness, I'd consider it as a bug in xkbcomp (i.e.
libxkbfile actually).

Here is another test:
  $ setxkbmap -model pc105 -layout ben,us -variant basic, -print
  xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+in(ben)(basic)+us:2"      };
        xkb_geometry  { include "pc(pc105)"     };
  };

But if in rules/base, section
  ! model    layout[1]   variant[1]  =   symbols
is moved *before*
  ! model    layout[1]               =   symbols
then I get:
  $ setxkbmap -model pc105 -layout ben,us -variant basic, -print
  xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+in(ben)+us:2"       };
        xkb_geometry  { include "pc(pc105)"     };
  };
which is just fine.

Unfortunately doing the same for 2nd layout does not help:
  $ setxkbmap -model pc105 -layout us,ben -variant ,basic -print
  xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+in(ben):2+in(ben)(basic):2"      };
        xkb_geometry  { include "pc(pc105)"     };
  };

My conclusions so far are:
  * Most specific sections must always appear before generic
    ones in rules/base.
  * Scripts in rules/compat/*.sh must be fixed so that when
    an old layout in layoutRename.lst is expanded into an
    expression with a paren, the %(v[N]) part is omitted.
    With these 2 changes, compat rules should be fixed for
    the first layout.
  * xkbcomp seems to handle the first layout in a special
    way; other layouts should be fixed as well so that
    when a
       model[N] layout[N] variant[N]  =   symbols
    section matches,
       model[N] layout[N]             =   symbols
    is ignored.

It would also be nice to put comments into *Rename.lst files,
which are of course removed when rules/base is written, to
keep track of dates of additions and remove those entries
after a sufficient amount of time.

*** Bug 17184 has been marked as a duplicate of this bug. ***

Denis, if you're still around, I'd love some more discussion about your proposals...

> * Most specific sections must always appear before generic
    ones in rules/base.
As I understand, this means:
- "numbered" sections should go before "unnumbered"
- sections with variants should go before sections with just layouts
Right? Am I missing anything in your idea?

> * Scripts in rules/compat/*.sh must be fixed so that when
    an old layout in layoutRename.lst is expanded into an
    expression with a paren, the %(v[N]) part is omitted.
    With these 2 changes, compat rules should be fixed for
    the first layout.
Good point. Clearly a bug here. Committed a fix (please check).

  * xkbcomp seems to handle the first layout in a special
    way; other layouts should be fixed as well so that
    when a
       model[N] layout[N] variant[N]  =   symbols
    section matches,
       model[N] layout[N]             =   symbols
    is ignored.
Should we open a separate bug against xkbcomp?

For #2, the fix is

http://cgit.freedesktop.org/xkeyboard-config/commit/?id=f914bfdf5016461cbe849dea21b9056f3c6149a7

Just for the record...

Hi Sergey,

debian bug#515152 seems related:
'setxkbmap cz_qwerty' gets remapped to cz(qwerty), but 'setxkbmap us,cz_qwerty' doesn't.

Cheers,
Julien

Julien, does debian include compatibility rules (in the configure params)?

> --- Comment #9 from Sergey V. Udaltsov <svu@gnome.org>  2009-04-22 08:13:12 PST ---
> Julien, does debian include compatibility rules (in the configure params)?

we don't explicitly disable compat_rules, so that should be enabled.

It seems there was a real bug in the compat rules processing. Could you please check from git?

> --- Comment #11 from Sergey V. Udaltsov <svu@gnome.org>  2009-04-22 13:23:45 PST ---
> It seems there was a real bug in the compat rules processing. Could you please
> check from git?

looks good, thanks much!

*** Bug 26088 has been marked as a duplicate of this bug. ***