1:08 p.m.
On Mon, Jul 7, 2014 at 9:15 AM, Jerry James <loganjerry(a)gmail.com> wrote:
On Mon, Jun 23, 2014 at 1:03 PM, Jerry James
<loganjerry(a)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/
1:29 p.m.
On Fri, 11 Jul 2014 12:08:23 -0600
Jerry James <loganjerry(a)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
10:40 p.m.
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.
Bill
10:33 a.m.
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
3595
days inactive
3598
days old
3 comments
4 participants
participants (4)
-
Bill Nottingham -
Jerry James -
Kevin Fenzi -
Paul W. Frields