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.
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.
Fedora-packaging mailing list
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
Perhaps I've missed something.
Jack Neely <jjneely(a)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