On Wed, 2005-12-14 at 17:40 -0500, Mike McLean wrote:
Jeremy Katz wrote:
The incompatibility is more in the repo metadata than in yum -- yum 2.4.x (which is what's on the build hosts) doesn't understand the new comps format. And that's partly because the comps side of things has had a lot less thought and effort put into making sure that it covers the needs of the userbase. And I'm going to go out on a limb and say that I expect this _not_ to be the last time it changes... we're actually starting to use the information and so I'm all but certain that we'll find things that we hadn't considered.
I was thinking more along the lines of the "new yum can't parse old comps" issue. If it could, it seems like we could just migrate to the new yum in the buildsystem.
Only if the new yum doesn't require pulling in lots of other stuff. And it's far better to just be able to use _any_ yum. Otherwise, eg, people won't be able to build for the devel tree on old releases without upgrading their yum.
For that matter, if the old yum could be told to ignore comps on a per-repo basis, we could work around it that way.
That should work -- set enablegroups=0 in your repo config file.
Let me throw out another possibility. Add a mock config option named buildcomps containing a url. If this option is present, have mock parse that comps and issue the appropriate yum install commands instead of a groupinstall.
Then mock has to grow how to parse a comps file. And which format should be preferred? If we were to go that route, we're better off just putting a list of packages in the mock config file, but that's just painful from a maintenance perspective, IMHO
Well, there's pain all around. Personally I think having to rebuild packages every time I make a buildgroups change is painful. I also think that being required to have fake packages in my buildroots is annoying.
At least with my suggestion you can point mock at a comps file you are confident it will be able to parse. By making it a url, you can still centralize that portion of the config.
mock doesn't do the parsing, though (or any downloading of files at all) -- all of that is in yum. To make mock do the parsing would need a) mock to be able to download files b) mock to be able to parse the comps file
That seems somewhat less than ideal to me
Jeremy