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@xxxxxxxxx) 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
