Comps fails to validate (patch inside!)

[Bill Nottingham]

As the guilty party in many cases for not updating the .rng file...

Kevin Fenzi (kevin at scrye.com) said: 
> > The comps-el4.xml.in and comps-el5.xml.in changes remove a nearly
> > empty <group> named "editors".  The description claims that the group
> > contains emacs and vi, but it doesn't.  All it contains is an XEmacs
> > metapkg.  As an XEmacs developer, I am flattered that our product was
> > included, but the current comps.rng knows nothing of <metapkg>.  This
> > looks like it was mistakenly included, or mistakenly not removed all
> > the way, hence the removal.
> 
> Seems fine. 

As Kevin said, EPEL groups are additive to RHEL groups; the descriptions are
supposed to match what they are in RHEL/CentOS if they share the name of a
group in EL. Hence, you can remove an empty 'editors' group, but I wouldn't
change the description.

> > In comps-epel7.xml.in, we currently have an <environment> prior to any
> > <group>.  That is not allowed by comps.rng, which wants all <group>s
> > first, then <environment>s.  This patch moves the <environment> to
> > satisfy that restriction.  But there is something odd here.  That is
> > the one and only <environment> in the file.  Is this a mistake?
> > Should there be <environment>s in comps-epel7.xml.in at all?  If so,
> > where are the rest of them?
> 
> epel comps files are additive to rhel comps files. So, they will be
> much smaller in general and not have any of the base env stuff. 
> I don't know off hand if rhel7 uses env's, but I think so. 

It does.

> > In addition to the dangling "clustering" reference that started this
> > thread, comps-f18.xml.in, comps-f19.xml.in, comps-f20.xml.in,
> > comps-f21.xml.in, and comps-f22.xml.in all have a libreoffice group
> > that is missing <default> and <uservisible> elements.  i took my best
> > guess at what the values of those elements should be.  In addition,
> > all but comps-f18.xml.in have a <group> named "3d-printing".  However,
> > that is not a valid ID, because it starts with a digit.  I changed it
> > to "three-d-printing", but somebody can probably come up with a better
> > name than that.
> 
> Fun. 

Please don't change group names in released releases - it's essentially an
ABI for kickstart files, and we don't want to break those. I suspect the fix
here is to change the definition to allow groups that start with a number -
yum handles this OK.


> > There are quite a few <packagereq> elements that do not carry a "type"
> > attribute.  It looks like comps.rng is supposed to support this, and
> > that those elements are supposed to default to the type "optional".
> > However, the "type" attribute has to be <optional> for that to work.

It's not optional - having no type set makes the type 'mandatory'. From the
yum code:

                genre = child.attrib.get('type')
                if not genre:
                    genre = u'mandatory'

The logic is that for groups that are used as building blocks of
environments, they're not intended to be modified - so all packages are
mandatory, and there are no optional/defualt ones.


> > In the "core" group, there is a package declared like this:
> > 
> >       <packagereq arch="armhfp"
> > type="mandatory">uboot-tools</packagereq>
> > 
> > but comps.rng doesn't know anything about an "arch" attribute.
> > Assuming that this is actually correct, and that consuming tools know
> > to expect such an attribute, I added support for this to comps.rng.
> 
> No idea here. Dennis and/or other arm folks might know more.

yum doesn't use arch= here, but it's used by some tools that process comps
files to write new ones. It's fine to add it to comps.rng.

> > Finally, in some <environment>'s <optionlist>'s <groupid>s, a
> > "default" attribute has appeared.  The current comps.rng does not
> > allow that.  Once again, assuming that this is actually correct and
> > that consuming tools expect that attribute, I added support for it.

Yes, that's correct.

Bill