[Yum-devel] groupreq in yum-2.6?

Panu Matilainen pmatilai at laiskiainen.org
Fri May 12 18:26:18 UTC 2006


> 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.
>
> so we could do:
> yum groupinstall phy-workstation
>
> and have that resolve out to installing
>
> @phy-base
> @phy-gui-tools
> @phy-backups
> @phy-math-crap
>
>
> but also have:
> yum groupinstall phy-server
>
> resolve out to:
> @phy-base
> @phy-backups
>
>
> 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.

This is exactly what we're doing at work as well. I was about to start 
looking into making the groupreq processing fully recursive to take full 
advantage of this when the groupreq got dropped from the new 
comps/yumgroups format :-/

> 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.

Exactly.

> 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.
> 2. use something like glump to create yum shell scripts that you then
> pass to yum:
>  so like above:
>   groupinstall phy-base
>   groupinstall phy-backups
>   groupinstall phy-gui-tools
>   groupinstall phy-math-crap
>   run
>
> would be the yum shell script for my phy-workstation profile.

I like the idea of separate profile tag. The needs are rather different 
from interactive anaconda/pirut-type use, so make it a separate tag, and 
"profiles" is exactly what this type of usage is all about really.

Instead of "only used by yum (cli application)" I'd rather see it as 
"implemented in yum libs, used where it makes sense" kind of thing: I 
think it'd be a pretty cool native kickstart feature but doesn't really 
make sense for pirut. And certainly I'd want to add support for it in 
repoquery so you can easily see what would actually get installed with 
your profile definitions etc.

 	- Panu -





More information about the Yum-devel mailing list