why you should not trim your system install

I happen to think it's *mostly* pointless to trim the install of a system's packages. When I install a system, be it a desktop, server, development machine, etc I install all available packages for that distro. A lot of people disagree with me. They usually say:

• "All those packages take up space!"
  
  Go buy a hard drive made this decade. And while you're at it, stop partitioning your kicks with 2GB /usr partitions and 500MB /tmp partitions. If your disk is full it's full; there's no benefit in letting it fill up sooner than later. Your filesystem should have been created with at least a 1% reserve for root only, which will allow you to log in and fix the issue (unless you are running filesystem-writing apps as root; you're not, right?) not to mention the system monitors you use to tell you before the disk fills up.
  
  
• "But it's a security risk!"
  
  Do you really think your system is more secure because it lacks some binary files? While you're spending time trimming your package list, you're forgetting the basics of system security like firewalling, disabling services, checking the filesystem for overly-permissive files/directories, setuids, etc. Just because you didn't install that setuid kppp doesn't mean there isn't a hole somewhere else on your system. Do a proper audit of your system once everything is installed. This will eliminate typical system attacks and you'll be secure enough to handle exploits in userland apps.
  
  
• "It takes extra time to update all those packages!"
  
  Is your network that slow? Even if you upgraded all of KDE or Gnome it shouldn't take but a couple minutes to download the updated packages. Of course you were a good admin and you have a kickstart repository on the LAN of each machine (or accessible a hop or two away) so the bandwidth should be immaterial.
  
  
• "Yum/apt will take care of the extra packages if you need to install something later."
  
  Oh boy! Let's talk YUM, shall we? First of all it's one of the shittiest pieces of vendor-approved package managing/updating software ever. Read the source if you dare (and if you can). The only thing that's more retarded than its code is how retarded it is to have to troubleshoot YUM when it doesn't do what you want to do. Let's go down the checklist:
  
  
  1. Run `yum clean all`
  2. Check that the package's --requires exist in packages in the repo
  3. Check that the 'meta' arch of the package matches the arch of the machine
  4. Make sure there isn't a duplicate package with a different arch in the repo
  5. Make sure there isn't a package with a similar name but higher epoch in the repo
  6. Make sure the name is the same
  7. Make sure the version is higher and has the same exact format as any other package with the same name
  8. Make sure the metadata in the repo is up to date, and re-gen it just to be sure
  9. Do a `yum clean all` again
  10. Sacrifice a goat to the Yum maintaners
  11. Rename your first born to 'Yellowdog'
  12. Etc
  
  
  Usually someone pushing a bad package or a dependency of a package that used to work will be what breaks Yum. It'll go unnoticed until you really really need that package and its dependencies installed. Then you'll spend hours (and sometimes days) trying to get it installed and fix whatever was broken with rpm/Yum. Whereas if you had installed everything right after your kick, the package would just be there, ready for use. You should only use something newer than what came with your kick if you really really need it.
  
  Of course experience teaches us the folly of trusting any update to an rpm. Whenever you push a new package you must test it on the host it'll be installed on. The package itself may not install correctly via Yum (though using just RPM would probably work), or there could be some other problem with the contents of the package that you'd only know by running the programs contained in the package on the target host. Because we do this, we don't need Yum to browbeat us every time the RPM (or something else) isn't 100% to its liking. If you just install packages en-masse and test them you can skip the whole process of troubleshooting Yum and skip right to troubleshooting the package itself on the host it's intended for, which we'd be doing anyway with Yum.
  

For a VPS or some other disk-and-bandwidth-limited host it's obvious that trimming packages will save you on both of your limited resources. But on a normal network with multiple hosts and plenty of storage I wouldn't spend a lot of time time tweaking my kickstart packages list.