Comps fails to validate (patch inside!)

Jerry James loganjerry at gmail.com
Fri Jul 11 18:08:23 UTC 2014


On Mon, Jul 7, 2014 at 9:15 AM, Jerry James <loganjerry at gmail.com> wrote:
> On Mon, Jun 23, 2014 at 1:03 PM, Jerry James <loganjerry at gmail.com> wrote:
>> There is a reference to a "clustering" group inside the "servers"
>> category in comps-f21.xml.in, but no definition of "clustering"
>> anywhere that I can see.  Also:
>>
>> [comps]$ make validate
>> ...
>> comps-f21.xml:46: element packagereq: Relax-NG validity error :
>> Element packagereq failed to validate attributes
>> comps-f21.xml:46: element packagereq: Relax-NG validity error :
>> Element packagelist has extra content: packagereq
>> comps-f21.xml:118: element packagereq: Relax-NG validity error :
>> Element packagereq failed to validate attributes
>> comps-f21.xml:118: element packagereq: Relax-NG validity error :
>> Element packagelist has extra content: packagereq
>> comps-f21.xml:73: element group: Relax-NG validity error : Invalid
>> sequence in interleave
>> comps-f21.xml:73: element group: Relax-NG validity error : Element
>> group failed to validate content
>> comps-f21.xml:73: element group: Relax-NG validity error : Expecting
>> element environment, got group
>> comps-f21.xml:73: element group: Relax-NG validity error : Element
>> comps has extra content: group
>> comps-f21.xml fails to validate
>> ...
>>
>> Is that output expected?  I see similar output from comps-el4.xml,
>> comps-el5.xml, comps-f18.xml, comps-f19.xml, and comps-f20.xml as
>> well.
>
> Neither of these has been fixed, and we're about to branch, which will
> spread the rot to yet another comps file.  For the second problem, the
> output of "jing -i comps.rng comps-f21.xml" seems a bit more
> comprehensible:
>
> comps-f21.xml:46:19: error: element "packagereq" missing required
> attribute "type"
> comps-f21.xml:47:19: error: element "packagereq" missing required
> attribute "type"
> comps-f21.xml:48:19: error: element "packagereq" missing required
> attribute "type"
> ...
> comps-f21.xml:512:19: error: element "packagereq" missing required
> attribute "type"
> comps-f21.xml:516:11: error: element "group" incomplete; missing
> required elements "default" and "uservisible"
> comps-f21.xml:543:19: error: element "packagereq" missing required
> attribute "type"
> ...
> comps-f21.xml:17630:19: error: element "packagereq" missing required
> attribute "type"
> comps-f21.xml:18405:25: error: character content of element "id"
> invalid; must be an XML name without colons
> comps-f21.xml:18518:31: error: found attribute "default", but no
> attributes allowed here
> comps-f21.xml:18691:31: error: found attribute "default", but no
> attributes allowed here
> comps-f21.xml:18692:31: error: found attribute "default", but no
> attributes allowed here
>
> The following comps files are currently failing to validate due to
> these and similar issues:
> comps-el4
> comps-el5
> comps-epel7
> comps-f18
> comps-f19
> comps-f20
> comps-f21

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

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.

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?

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.

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.

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.
-- 
Jerry James
http://www.jamezone.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comps.patch
Type: text/x-patch
Size: 17648 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140711/cbb6af23/attachment-0001.bin>


More information about the devel mailing list