comps.dtd; metapkg

David Kewley kewley at cns.caltech.edu
Sun Mar 14 08:49:44 UTC 2004


I've made a comps.dtd (attached) that validates the RHL 9 comps.xml using 
xmlproc_val, and which (to the best of my ability) expresses the logic in 
/usr/lib/python2.2/site-packages/rhpl/comps.py.  I only started learning 
XML yesterday evening, so there may be problems.

I'm not sure what the dtd is useful for except validating. :)  But as for 
validity (as opposed to well-formedness), the only thing that appears to 
really matter for comps.xml is whether comps.py can parse it.  Which of 
course it can.

Note that comps.py has some requirements that the comps.dtd doesn't specify 
(e.g. that there must be a name for each group).  I would specify this 
requirement, but I only know how to do that by specifying a child order in 
the dtd.  comps.xml has groups with children in different orders.  I don't 
know how to specify in the dtd "this child must exist exactly once, but it 
can appear as any child".

Note also that I included "requires" as a possible child for group.  
comps.py says this isn't in use any more, but it does parse it.

And finally, I see that the element metapkg is only used in the RHL 9 
comps.xml in one place:

  <group>
    <id>editors</id>
    <name>Editors</name>
...
    <grouplist>
      <groupreq>base</groupreq>
      <metapkg type="default">emacs</metapkg>
      <metapkg type="optional">xemacs</metapkg>
     </grouplist>
    <packagelist>
      <packagereq type="default">vim-enhanced</packagereq>
      <packagereq type="optional">vim-X11</packagereq>
    </packagelist>
  </group>

Looking through the anaconda code didn't help me figure it out quickly, and 
I didn't find anything useful on the web, so let me ask: what is a 
metapackage?

David
-------------- next part --------------
<!ELEMENT comps (group+, grouphierarchy?, package+)>


<!ELEMENT name (#PCDATA)>
<!ATTLIST name xml:lang CDATA 'en_US'>


<!ELEMENT group ((id | name+ | description+ | uservisible | default |
    requires* | langonly* | grouplist? | packagelist?)*)>
<!ELEMENT id (#PCDATA)>

<!ELEMENT description (#PCDATA)>
<!ATTLIST description xml:lang CDATA #IMPLIED>
<!ELEMENT uservisible (#PCDATA)>
<!ELEMENT default (#PCDATA)>

<!ELEMENT langonly (#PCDATA)>

<!ELEMENT grouplist (groupreq+, metapkg*)>
<!ELEMENT groupreq (#PCDATA)>
<!ATTLIST groupreq type CDATA #IMPLIED>
<!ELEMENT metapkg (#PCDATA)>
<!ATTLIST metapkg type CDATA #IMPLIED>

<!ELEMENT packagelist (packagereq+)>
<!ELEMENT packagereq (#PCDATA)>
<!ATTLIST packagereq type CDATA #IMPLIED requires CDATA #IMPLIED>


<!ELEMENT grouphierarchy (category+)>
<!ELEMENT category (name+, subcategories?)>
<!ELEMENT subcategories (subcategory+)>
<!ELEMENT subcategory (#PCDATA)>


<!ELEMENT package (name+, dependencylist)>
<!ELEMENT dependencylist (dependency*)>
<!ELEMENT dependency (#PCDATA)>


More information about the fedora-devel-list mailing list