Red Hat Bugzilla – Bug 16008
RFE: rework how 'everything' option is presented (or remove it)
Last modified: 2007-11-30 17:10:30 EST
Summary says it all.
Rationale: minimize errors of inexperienced users.
Longer rationale: the "Everything" option installs *everything*, when most
newbies interpret it to be a simple "All of the above" choice which installs all
components. Instead, they get a lot of things that don't even belong to any
components and which the vast, vast majority of people have no reason for. This
leads to having a lot of junk installed, including unnecessary suid programs,
servers, and other potential security holes.
Suggestion: make an option which installs all of the rpm package files
themselves (perhaps into a directory in which some of the user-friendly RPM
tools know to look). That way, someone who doesn't know what they're doing can
still easily have everything accessible after the install, without having put
the aforementioned junk everywhere.
Moved to future feature list.
Moving to RESOVLED - DEFERRED from CLOSED - DEFERRED
Since this part of anaconda is being reworked, seems like an excellent time to
My current plan is to not put Everything back as an option at all -- it'll
probably remain for kickstart although I'm not even 100% sure there
For what it's worth, I've been patching it out of my anaconda build for years,
and every now and then someone complains, and that basically gives me an
opportunity for a spiel about decent admin practices, after which they're so
bored they totally give on complaining. :)
Anyway, with how yum and friends make it so easy to add missing bits,
"Everything" is even less generally useful than it was when this was filed.
I protest. Why close the door on a useful option? For the sake of purity? Heck, we have Debian for that. Surely a workable, secure "everything" can be put together? For that matter, where's the documented history of failures because of its presence to date? Not all users needs are the same. Everything is a reasonable option--probably for the majority of users actually.
Janina -- I've had users with systems broken into that wouldn't have been if
they'd only installed software they needed. Do a "majority of users" need
supercomputing message-passing libraries? Do a majority of users need every
server daemon running? Does everyone need Postfix, Sendmail, *and* Exim installed?
How is that even useful?
Indeed, not all users' needs are the same -- so pick what you need. (Or install
it via yum.)
*** Bug 174092 has been marked as a duplicate of this bug. ***
I'm referring to my duplicate bug #174092:
Ok, I can report packages that were not installed (although they are on the 5
install CDs and I selected all available package groups) as a new bug to the
comps package. Just out of curiosity: How comes that these rpms are at all on
the install CDs? I guess they are intended to be installed? Are the links to the
proper package groups just missing or how do you decide which packages are in
the default comps file?
I've now opened a new bug on comps (#174244) and attached a complete list of all
the packages that were not installed although all available package groups were
selected during FC5T1 install. The list contains 999 rpms so something must have
gone really wrong here.
Those packages arguably are candidates to be moved from Core to Extras, yeah.
But that's a separate issue.
What? You must be kidding. You honestly want to put all the *-devel packages,
mc, smartmontools, dhcp and other into Extras?
Have you actually had a look on the package list?
The devel packages are generated as part of the same source RPM as the main
ones, so they can't really move to extras. Many of them *aren't* useful to most
people, even developers, because they're only useful for developing extensions,
etc. for that particular program. Many other -devel packages are included in the
various Development groups.
Midnight Commander is a *great* candidate for extras.
DHCP is already in a group: Network Servers.
Not sure why smartmontools isn't included.
And yeah, I've looked at the package list more than I care to. :)
But anyway, these specific cases should get individual bugs. I'll take a look at
your bug #174244.
The midnight commander is a very useful application and is a system utility. Why
the tool is not installed by default is a dreadful practice.
As the argument stated regarding not being able to access many useful programs
that are on the install CDs, it makes no sense to not be able to access these
programs during installation.