On Fri, 11 Jul 2014 12:08:23 -0600 Jerry James <loganjerry@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
