mock and fc5/fe5 and comps pain

[Jeremy Katz]

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