Bug 16008 - RFE: rework how 'everything' option is presented (or remove it)
RFE: rework how 'everything' option is presented (or remove it)
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
: FutureFeature
: 174092 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-08-11 13:04 EDT by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-24 22:20:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gene Czarcinski 2000-08-11 13:04:59 EDT
Summary says it all.

Rationale: minimize errors of inexperienced users.
Comment 1 Matthew Miller 2000-08-13 16:44:10 EDT
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.
Comment 2 Michael Fulbright 2000-08-17 11:31:08 EDT
Moved to future feature list.
Comment 3 Michael Fulbright 2000-09-26 12:10:47 EDT
Comment 4 Michael Fulbright 2000-09-26 12:56:29 EDT
Comment 5 Matthew Miller 2005-11-24 11:14:21 EST
Since this part of anaconda is being reworked, seems like an excellent time to
revisit this.
Comment 6 Jeremy Katz 2005-11-24 22:20:32 EST
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
Comment 7 Matthew Miller 2005-11-24 22:27:43 EST

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.

Comment 8 Janina Sajka 2005-11-25 12:58:18 EST
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.
Comment 9 Matthew Miller 2005-11-25 13:07:40 EST
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.)
Comment 10 Matthew Miller 2005-11-25 18:49:04 EST
*** Bug 174092 has been marked as a duplicate of this bug. ***
Comment 11 Bernd Bartmann 2005-11-26 06:31:10 EST
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?
Comment 12 Bernd Bartmann 2005-11-26 07:52:14 EST
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.
Comment 13 Matthew Miller 2005-11-26 08:57:54 EST
Those packages arguably are candidates to be moved from Core to Extras, yeah.
But that's a separate issue.
Comment 14 Bernd Bartmann 2005-11-26 09:13:59 EST
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?
Comment 15 Matthew Miller 2005-11-26 09:31:07 EST
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.
Comment 16 Jim Cornette 2006-01-25 06:59:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.