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