[Yum-devel] groupreq in yum-2.6?
pnasrat at redhat.com
Fri May 12 16:29:05 UTC 2006
On Fri, 2006-05-12 at 11:59 -0400, seth vidal wrote:
> On Fri, 2006-05-12 at 09:35 -0400, Brian Long wrote:
> > > 1) To artificially pull in deps - this is wrong if a package depends on
> > > something the dependencies should all be explicit.
> > >
> > > 2) Groupings of groups for ui tools - this has been replaced with
> > > categories in the new metadata format.
> > >
> > > I believe the rationale was that that it was really overridden behaviour
> > > expected from groupreq - and splitting out the ui component to
> > > categories for logical grouping and letting the packages take care of
> > > the deps was the right thing to do.
> > >
> > > What precisely are you trying to achieve with groupreq? Lets see if we
> > > can figure a way to do what you want.
> > https://lists.dulug.duke.edu/pipermail/yum/2006-April/008627.html
> This is similar to what I used to do in physics:
> for our kickstart %posts we would define a bunch of subgroups and pull
> them into a larger metagroup.
I can see how people have been using groupreq.
> and not have to touch the other groups at all, including for doing
> things like:
> yum groupupdate phy-server
> and have it pull in sub-deps, etc.
> The virtue of doing it all in the yumgroups.xml file is that it is:
> 1. painfully simple
> 2. requires no infrastructure you didn't already have.
OK - those are reasonable requirements.
> So a couple of solutions:
> 1. we add in a profile tag to the comps parsing that is just a way of
> collecting groups and is only used by yum. Not as tidy b/c it seems like
> it might be the wrong place for it.
Indeed, the more that I think about it I think that categories should be
moved outside of comps.xml too, both are site/distro specific and not
really core package grouping functionality. They're together at the
moment mainly because of the historical relationship between anaconda
If we are thinking about how YUM itself should be using groups, I really
think it doesn't care about this extra metadata, but I can see how some
people care about hierarchical groupings. Part of the problem is that
it's all pretty loosely defined (and mostly design by implementation).
Also the way that we figure if a group is installed is pretty icky.
As far as the system goes, there are just packages. We've got some ways
of defining these in higher level blobs but we're not very exact about
what that means. Lets get a comps.xml schema written, think about the
meaning of groups, and figure out how we can let people manage software
groupings with yum.
More information about the Yum-devel