Comps fails to validate (patch inside!)

[Kevin Fenzi]

On Fri, 11 Jul 2014 12:08:23 -0600
Jerry James <loganjerry at gmail.com> wrote:

> I'm surprised that there have been no replies to this.  Currently,
> people who edit the comps files can't tell if they broke something,
> because the current batch of files already fails to validate.  I'm

Yeah, this started happening a while back. I tried to fix it and ran
out of time and it fell off my radar. ;( 

> attaching a patch that fixes all of the validation failures, but I am
> not going to commit it because: (1) I am about to be out of touch for
> a week and a half, (2) more eyes should look at this patch before it
> is applied, and (3) it should really be a sequence of patches with
> separate git commits instead of one big patch.

I suppose. I'd be fine with you commiting now... and if it breaks
things worse case is we just revert it. I'd be happy to watch and
revert if need be. 

> 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. 

> 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. 
 
> 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. 
> 
> 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.
> 
> 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. 
 
> 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.
> 
> I won't be around to respond to any replies to this for about 10 days.
> Sorry.  HTH.

Thanks for working on it anyhow. Much appreciated. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140711/a59d5dd3/attachment.sig>