[Yum] groupreq and yum 2.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2006-04-10 at 22:06 -0400, seth vidal wrote:
> On Mon, 2006-04-10 at 20:20 -0400, Jeff Sheltren wrote:
> > On Apr 10, 2006, at 4:27 PM, Panu Matilainen wrote:
> > >
> > > Group dependencies are no longer supported in FC-5 comps/yumgroups.xml
> > > format. I miss them too... but the groupreq got sacrificed for the GUI
> > > gods, expressing the group dependencies in GUI tools doesn't really
> > > work.
> > >
> > > 	- Panu -
> > 
> > So, I've been curious - is there a new "more better" way to do this  
> > in yum 2.6?  I get the impression that the comps format (ie.  
> > yumgroups.xml) is going the way of the dodo bird.  Seth has brought  
> > up alternatives for how mock should handle this, but I'm unaware of  
> > how "groups" are/will be handled in yum 2.6+.  Is this still under  
> > development?  Is it an underground movement to do away with the  
> > segregation of packages? :)  If it has already been decided, is there  
> > a place I can read about groups support in current versions of yum?
> > 
> 
> in order to make the gui work we had to minimize some of the crazy
> recursive possibilities of groups and pull out some other difficult
> concepts. I'm not adverse to putting some of the things back in  but I'd
> want to make sure it's done in conjunction with things that anaconda
> needs to make sure we don't break the installer for fedora. :)
> 
> What functionality is it that you need from the groups and let's see if
> there is a happy medium in here somewhere?

My group uses nested groups extensively for profiles on workstations vs.
servers, etc.  For example, we have various classes of workstations and
we have groups that add functionality depending on the class.  For
example, a base workstation has certain packages; an engineering
workstation includes the base workstation and adds other packages.  We
prefer to do one "yum groupinstall" for engineering workstation and have
it pull any nested groups as needed.

If yum-2.6 will not have this functionality, for RHEL 5, we would have
to move the source of truth for what gets installed on each workstation
class from inside the yum repo to some class-specific configuration in
our kickstart (i.e. we would have to know that on engineering
workstations, we need to yum groupinstall base-workstation and
engineering).  The movement of the source of truth is a fairly large
problem and we prefer for it to be centralized inside the yum repo /
yumgroups.xml.

Thanks for your help in this.

/Brian/
-- 
       Brian Long                      |         |           |
       IT Data Center Systems          |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux