The rules.xml file describes how AutoYaST creates the complete XML profile out of single XML snippet files. Like for example "if the main memory is more than 2GB, use kde.xml, else use windowmaker.xml", "if you find more than one harddisk, use lvm.xml, else use simple_partitioning.xml" ... and so on ...
That's available since ages in AutoYaST what's new now is, that you can present all XML snippets you have to the users so they can select which ones to use on their own.
Confused but curious? Then read on ....
A while ago I read a feature request on the AutoYaST mailinglist that it would be cool to have the <rules> visible and selectable during installation and I was thinking: "Sounds like a good idea. So why not?". So here it is.
People love pictures so lets start with a screenshot:
On the screenshot you can see a dialog where you can choose between two rules where the first one is pre-selected and the second one is greyed out because it conflicts with the first one (I'll explain later what that conflict means).Lets take a look at the interesting part of the rules.xml file now to see how to create such a dialog.
<rules config:type="list">
...
<rule>
<custom1>
<script>
<![CDATA[
echo -n 100
]]>
</script>
<match>100</match>
<match_type>exact</match_type>
</custom1>
<result>
<profile>rules/kde.xml</profile>
<continue config:type="boolean">true</continue>
</result>
<dialog>
<element config:type="integer">0</element>
<question>KDE Desktop</question>
<title>Desktop Selection</title>
<conflicts config:type="list">
<element config:type="integer">1</element>
</conflicts>
<dialog_nr config:type="integer">0</dialog_nr>
<timeout config:type="integer">30</timeout>
</dialog>
</rule>
<rule>
<custom1>
<script>
<![CDATA[
echo -n 100
]]>
</script>
<match>101</match>
<match_type>exact</match_type>
</custom1>
<result>
<profile>rules/gnome.xml</profile>
<continue config:type="boolean">true</continue>
</result>
<dialog>
<element config:type="integer">1</element>
<dialog_nr config:type="integer">0</dialog_nr>
<question>Gnome Desktop</question>
<conflicts config:type="list">
<element config:type="integer">0</element>
</conflicts>
</dialog>
</rule>
<rule>
...
</rule>
...
</rules>
That's not a complete rules.xml but only the interesting part with the two rules that created the dialog you see in the screenshot.
Here comes the description of the single XML elements:
- <dialog_nr config:type="integer">0</dialog_nr>
That's a uniq id for the a popup dialog. All rules with the same dialog_nr are presented on the same popup dialog. This element is optional and the default for a missing dialog_nr is always "0". If you have one popup only anyway, you don't need to specify the dialog_nr. - <element config:type="integer">0</element>
element needs to be a uniq id. Even if you have more than one dialog, you must not use the same id twice like an element-id "1" on dialog 1 and and element-id "1" on dialog 2 too. That's different than with <ask> dialogs, where you can have the same <element> id on multiple dialogs. I'll explain later why this is. - <title>Software Selection</title>
that's a text string at the top of the dialog. A caption for that dialog if you want so and it's optional. If you configure multiple titles for one dialog, the last one is used. - <question>KDE Software Selection</question>
That's the text string behind the checkbox. If you don't configure a question, the name of the XML file that is triggered by this rule will be shown instead (in our example above, that would be "rules/kde.xml" and "rules/gnome.xml"). If you know what's in kde.xml and gnome.xml you maybe don't need the <question> but I'd prefer a short explaining text over just a filename. - <timeout config:type=""integer">30</timeout>
if you don't answer the dialog in "timeout" seconds, AutoYaST will continue.
As soon as you touch one checkbox or button, the timeout stops for this popup and you have to press "okay" to continue. The next dialog can have a new timeout then. - <conflicts config:type="list">
here you can specify a list of element id's that conflict with this XML file. If you select this XML file, the conflicting one(s) will be deselected and disabled. Be careful what you configure here, you can create deadlocks. An element can conflict with another element on a different dialog and that's the reason why element id's have to be uniq.
Whether a question is pre-selected or not is defined by the result of the rule. In my example above, I configured a rule that matches always (100 = 100) and a rule that matches never (101 = 100). Without dialogs, such a rule file would not make a lot of sense because gnome.xml would never be used but here I use them to do the default pre-selection.
So again, if a rule matches, the file (kde.xml in our example) is pre-selected.
That means, if you add dialogs to your already existing rules.xml that has no dialogs yet and you set a timeout, your autoinstallation process will be the same like before, except that you'll see a popup dialog for "timeout" seconds. The rules work like before and you can see which ones have matched in the popups.
To sum things up:
All dialog configuration is done in the rules.xml file. Each <rule> can have one <dialog> which represents one checkbox on a dialog popup. You can have multiple dialog popups and you can have multiple rules (checkboxes) on one dialog popup.
This feature is officially implemented for openSUSE 11.3 but since openSUSE 11.2 is brand new and out for just a few days now, I made a driverupdate_11.2.tar.bz2 to make the feature available for openSUSE 11.2 too. If you want to try it, download and extract the file and copy the "driverupdate" file to the root of your installation source to get that feature on openSUSE 11.2.
Feedback is appreciated.
Thanx to Stacey Murphy and Martin Vogt for the idea.
have fun creating your own rules ;)
Uwe
