mock and fc5/fe5 and comps pain

[Jeremy Katz]

On Wed, 2005-12-14 at 15:10 -0500, Mike McLean wrote:
> seth vidal wrote:
> >  As some of you are aware the comps changes that anaconda wanted changed
> > how comps works in yum which nicely BROKE Fedora Extras rawhide builds
> > once the comps.xml changes landed in rawhide. So what do we do to fix
> > it? 
> 
> I realize this might be an odd time for me to jump into the discussion,
> but a few concerns and questions leap to mind. Perhaps some of these
> stem from my imperfect knowledge of the situation; if so, I apologize.
> 
> First, isn't this an odd sort of incompatibility to introduce in yum?
> Even if this solution is applied in mock, that is no insurance against
> further incompatible yum changes in other areas.

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.

> It seems to me that this problem could be resolved at the repo level.
> Couldn't plague maintain its own copy of the rawhide repo sans comps?

It's more than just the devel repo -- it'll then be the fc5 repo and the
devel repo.  Plus the extras counterparts.  Plus everyone on older
releases trying to build against fc5/devel using mock.  

> I guess my points are:
> 1) not all mock users will be impacted by this issue (I won't, since I
> generate my own repos).

All mock users will be impacted because you're not guaranteed that the
version of yum you have can handle the group information in the
repository. 

> 2) If this change is applied in mock, it will impact mock users unless
> the new behavior is optional.
> 
> 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

Jeremy