On 7/10/08, Brett Lentz <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-07-10 at 11:15 -0400, Bill Nottingham wrote: > > Ed Brown ([EMAIL PROTECTED]) said: > > > Sorry, but 'sensible security' sounds too much like politico or > salesman > > > speak for "everything works out of the box!" > > > > When the alternative is "wait, you can't talk to the network because > > ISDN/bridge tools/etc. aren't installed", absolutely. > > > > The reason things like that are installed in the default minimal > > install is that there's not a good mechanism to automatically grab > > hardware-specific packages specific to your machine. If something > > like that comes around, that can change. > > > > Nonsense. The tools already exist for everything but the automation. I > don't see where automation is being requested, but I do see where better > self-selection is being requested. As far as I can tell, there just > hasn't been any effort dedicated to refinement of the package grouping > and selection process. The same basic group structure of base, core, > etc. has existed since at least the RedHat 7.x days. > > The RHEL4 Anaconda supported comps.xml's groups requiring other groups, > which is the only feature required to easily do what is being requested. > > Rather than having the base and core groups bloated with non-essential > packages, it is possible to shift packages out of the base group, into > other package groups, and then simply create a new "default install" > group that includes all groups that RH wants to use as their "works on > 95% of systems out of the box" default installation. > > This is exactly what I've done at $dayjob. My base group is the barest > minimum required for a running kernel and a shell, then I build separate > package groups to optionally include relevant packages for the systems > I'm working with. Most of base gets shuffled into these separate groups, > so that I can still do a "typical install" if I want to, it's just > multiple package groups instead of all being in a single base group. > > > In the meantime, "%packages --nobase" in kickstart should solve your > > needs - if you're trying to install a large group of servers, you > > absolutely should be using kickstart. > > > > Most already are using kickstart. That isn't the point. The point is > that if RH adopted a more granular, flexible default package grouping, > there wouldn't be so many of us having to spend our time doing very > similar customizations at each of our sites.
How much of a problem is this with size and cost of disks now? I hate all the extra junk too, especially when its enabled by default, a cleanup and organization of groups/packages would be great, but just having it there seems like much less of a problem than it used to be.
_______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
