Re: Comps fails to validate (patch inside!)
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(a)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