Bug 139364 - Base and Core package list getting too large?
Summary: Base and Core package list getting too large?
Alias: None
Product: Fedora
Classification: Fedora
Component: comps   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-15 16:07 UTC by Aleksandar Milivojevic
Modified: 2014-03-17 02:50 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-07 00:03:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Aleksandar Milivojevic 2004-11-15 16:07:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914

Description of problem:
Is it just me, or the Base and Core groups of packages are becomming
bloated?  And I mean really way too bloated.  In RH 7.3, Base+Core was
around 250MB (and even that could have been a bit smaller).  Now it is
over 500MB, and it includes X11 and OpenGL libraries!?

In the old days, if I wanted to build dedicated server, I could simply
install Base+Core, and add package or two to support specific service.
 And be sure that there's isn't much not needed stuff that some script
kiddie could try to exploit.  With FC3 this isn't the case anymore. 
Core+Base looks rather bloated.  It could already be renamed to
"non-graphical workstation" or something.

Examples include stuff such as tcpdump, image libraries (jpeg, png,
tiff, on text-only install that will be used as dedicated firewall? 
give me a break), cups (wouldn't this belong in like printing or
print-server or whatever?), wireless, bluez-*, irda-* (laptop
specific, 99.9% of desktops and about 99.999% servers have absolutely
no need for those), pormapper, nfs stuff (very very rarely needed by
those who install only base+core).  This is just to mention few that
IMHO have no bussiness of being installed when only Core+Base groups
of packages are selected.  There are many more.

There are also some nice, but really not needed packages, that trigger
installation (through dependencies) of stuff such as X11 libraries,
OpenGL libraries, gnuplot, and some other crap.  Excellent candidates
for eviction too.

Anybody else feels it is time for *big* cleanup of Core and Base groups?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create ks.cfg and ask for only @Base and @Core.
2. Watch bunch of garbage being installed

Actual Results:  Bloated install.

Expected Results:  Minimal install.

Additional info:

Comment 1 Bill Nottingham 2004-11-15 21:16:17 UTC
I'm curious what would bring the following in:

a) X libs
b) cups

Have you done any dependency analysis?

Comment 2 Paul Nasrat 2004-11-15 21:19:42 UTC
Possibly rhpl->synaptics->x libs which I've since removed.

Comment 3 Aleksandar Milivojevic 2004-11-16 00:07:17 UTC
Yes, rhpl and synaptics is one thing.  There was some other stuff that
pulled X libs.  I believe one of the things that depended on X11
(directly or indirectly) were NetworkManager and
system-config-network-tui, but I'm not 100% sure.

I don't know what brought cups.  At the end, I compared with an
minimalistic Red Hat 7.3 Base+Core install and ended up with something
like this in my ks.cfg file.  I've left SELinux related stuff.  Maybe
I've gone a bit into rampage, and some of the excluded packages
reflect my personal needs (not-needs would be more apropriate term),
but IMHO at least 75% of this stuff isn't really needed for minimal
install, and should belong to some other package groups and/or should
be added by other parts of install process if/as needed.

Anyhow, it is always easier (and at the end of the day, more secure)
to add a package or two, as needed by site installation policies, than
to maintain lists like the one bellow.


Comment 4 Bill Nottingham 2004-11-16 04:37:23 UTC
A lot of the cruft is redhat-lsb and requires; I'd suspect if you
cleaned that out, you'd get a more reasonable number.

Comment 5 Aleksandar Milivojevic 2004-11-16 17:27:53 UTC
Hm, I've attempted to do an install with only redhat-lsb deselected. 
It didn't made any difference (277 vs 278 packages installed).

I'm looking into the list of Base (126 packages) and Core (54
packages) in comps.xml file.  This should give 180 packages in final
install.  However, 278 packages are ending up being installed on the
system.  BTW, any reason why Base is mandatory?  I've just tested
removing all non-Core packages, (and readding ssh packages).  I've
ended up with completely functional system that has only 116 packages
installed.  Actually, the more I look into it, the more it looks like
what Base+Core looked liked originally (in older Red Hat releases). 
There's maybe only a handfull of packages worth adding to this
core-only install (iptables, man pages, logrotate, logwatch, couple of

So, how about letting people select only Core group in ks.cfg? ;-)
Or to be more backward compatible, introducing a way to deselect Base

BTW, I rechecked cups package.  It seems nothging depends on it.  Why
was it installed, I have no idea...

Comment 6 Bill Nottingham 2004-11-16 17:36:43 UTC
You can select just core in ks.cfg.

cups is pulled in by the redhat-lsb dep on /usr/bin/lpr, I'm 99% certain.

Comment 7 Aleksandar Milivojevic 2004-11-16 19:14:31 UTC
Hmmm...  I think documentation says that core and base are always
selected.  Anyhow, I've attempted to do something like this:

   @ core

And I got both core and base plus dependencies installed: 278 packages.

As for cups, you are right about dependencies.  However, if I do this:

   @ core
   @ base

Again, I'm getting all those extra packages that redhat-lsb requires
(but not redhat-lsb itself): 277 packages.

I don't know what exact algorithm is used (or where to look to find
source for it), but looking at the install process as a black box, it
looks like as if the current algorithm is:

  - add core and base
  - add all other specified groups/packages
  - add all packages needed to satisfy dependencies
  - remove deselected packages

Or at least the end result is if the above algorithm was applied.

Somehow, I have a feeling that more correct algorithm would have last
two steps reversed:

  - add core (and maybe base?)
  - add all other specified groups/packages
  - remove deselected packages
  - add all packages needed to satisfy dependencies

There's really no point in installing dependencies, if the package
that depends on them is not going to be installed.

BTW, I've went through list of packages in base group.  Are all of
those really needed there?

Comment 8 Bill Nottingham 2004-11-16 19:28:42 UTC
Cc'ing the installer group for any comments on the algorithm.

Comment 9 Bill Nottingham 2004-11-16 19:29:37 UTC
I believe you need %packages --no-base to remove base.

Comment 10 Aleksandar Milivojevic 2004-11-16 20:09:31 UTC
I've just tried out %packages --no-base.  No difference.  I got both
core, base and all dependencies (278 packages in total).  Installation
hasn't complained, so --no-base option exists.  However it seems to be

Comment 11 Rodolfo J. Paiz 2005-01-14 19:10:58 UTC
Aleksandar's work closely parallels mine, although my definition of a
minimal install is right now around 150 packages using just over
400MB. There really are a ton of things in "minimal" that don't belong

I've documented my efforts at package removal in the "Bare-Bones
Server HOWTO" I am currently writing... see the "Trimming the Fat"


Also, I have begun to work on a kickstart file (barebones.ks) which
can be reached from that document or found directly at:


I am now attempting to begin modifying the comps.xml file to produce a
minimal install that mimics the end result of my efforts. The intent
is to submit it so that you guys can test it and hopefully modify the
minimal install in FC4... however, I will admit that my lack of
development expertise is making just the understanding of that bloody
file a slow process.

What can we do to eliminate all these unnecessary packages from
Fedora's minimal install?

Comment 12 Aleksandar Milivojevic 2005-03-04 16:28:47 UTC
The correct option to skip base group is:

%packages --nobase

It works on CentOS, haven't tried it with Fedora yet (should work,
both use same installer).

Comment 13 Joshua Daniel Franklin 2005-10-07 00:01:27 UTC
I verified that

%packages --nobase

works on RHEL4-U2 for a minimal-ish install. See 
for more details.

This could probably be filed as a kickstart documentation bug.

Comment 15 Bug Zapper 2008-04-03 15:46:29 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 16 Bug Zapper 2008-05-07 00:03:42 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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