[Fedora-packaging] Re: RFC: Creating meta group packages via comps

[Jack Neely]

On Tue, Aug 29, 2006 at 03:00:21PM -0400, Jeremy Katz wrote:
> On Tue, 2006-08-29 at 11:09 -0700, Christopher Stone wrote:
> > It should be really easy to make a script that builds metagroup
> > packages from comps, no?
> > 
> > This will allow someone to install a group such as kde/gnome as an rpm
> > package and when packages are removed/added/changed in the comps
> > groups, the meta group package also changes, and the user gets the
> > appropriate changes.
> > 
> > I don't think this is possible now with the groupinstall feature in
> > yum which IMO is a bad feature since it should be done with meta group
> > packages as I describe.
> > 
> > Comments?
> 
> The entire point here is that there don't have to be packages to keep
> track of this metadata -- so if you change comps, you don't have to go
> change lots of packages.  This is also really helpful for doing
> site-specific customizations of what the various groups are.
> 
> The argument about a "noob" is pretty much moot as they're far more
> likely to be using the graphical interface as opposed to yum on the
> command line.  And at that point, the comps file becomes even _more_
> important as it's used for the entirety of the display.
> 
> Jeremy
> 
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging

I agree that packages for maintaining this metadata is bad.

However, I do have issues related to this.  I build/maintain slightly
modified versions of FC/RHEL to support NC State University.  For
some time now administrators on campus have known that if they want a
stripped down server they can use kickstart and include the Server
group.  For workstations, the kickstart has one or two workstation
groups that install the standard setup.  

Now to install a workstation the kickstart needs to have...I think I
stopped counting at 15 groups.  This is slightly problematic in 2 ways.
I have a pretty big re-education effort (much more so than if the names
of the group changed or only 1 or 2 additions).  Also, there's a large
risk that one group or another will forget/add certain groups making my
managed clients less identical, harder to maintain, and even worse to
support.

Perhaps I've missed something.

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89