Comps fails to validate (patch inside!)

[Paul W. Frields]

On Sun, Jul 13, 2014 at 11:40:52PM -0400, Bill Nottingham wrote:
> 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.

It seems like there are a couple non-obvious gotchas here (additive
nature, kickstart dependency, et al.); would it make sense to put a
README in the comps repo pointing some of this out for posterity?

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com