further package removals/potential package removals

[Nicolas Mailhot]

Le dimanche 23 janvier 2005 à 02:12 +0000, Michael A. Peters a écrit :

> IMHO it should be easy for an OEM to start with a smaller base, rip  
> either KDE or GNOME out (depending upon what their staff is trained  
> in), rip the dev tools out, add some patented stuff (like GStreamer  
> plugins from fluendo or whoever) and have well under a gig of packages.
> 
> They can do that now, but it is harder because there is a lot more to  
> sift through.

What I want (and at at a point anaconda was real close to providing
this) is the following process :
1. boot on the first FC or RHEL disk
2. have an alphabetical list of the packages available where I can check
the core packages I need
3. have anaconda compute the deps of my core packages, and propose
either to pull all of them or let me review them one by one (ie display
a list of all the packages it wants to pull in, with the following info
for each of those packages: disk number, all the core dep chains that
pull it in, summary)
4. maybe a screen with package suggestions (new stuff in this release
that's great to have, optional plugins for the stuff I selected)
5. save the resulting ks on floppy or usb flash
6. ability to have the next anaconda release read this ks and restart
the selection process from there

Right now to achieve the same result you have to do a minimal install,
copy the kickstart, manually rpm -e and yum install all the stuff you
want, note all your ops and add th packages -packages to your ks copy,
boot on it to test it, etc

The in-system ks generator is a joke :
1. it's not clear on what steps/parameters are mandatory or not
2. it requires a system install just to generate the ks list
3. it requires the *same* system as the one you want to generate a ks
for. Needless to say on even a small network after a few years you have
to work with multiple RHEL/FC versions so do you really believe the
admins will have a bow with each freaking distro release in just to
manage their ks files (and that includes all the RHEL update releases,
because the package set is not stable even in those!)? They may even not
use a RHEL/FC box themselves !

The general RH bias is/was always to install more stuff when in doubt.
Make all optional plugins mandatory via explicit deps. Dumb down
anaconda so it's more difficult to trim the default rpm groups. Add a
few deps instead of splitting a package when a new release ships a new
utility that requires a behemot like openldap, mysql or perl. The result
is the massive bloat we have today (just when flash-root systems like
mini-itx boxes appear on the market). Plus all the anaconda tricks do
not protect from yum installations, nor manual kickstarts, because
people *want* to trim the installation and will even go to the package
rebuild stage to get it.

Really dependencies should be reviewed more carefully in the rawhide/FC
beta stage and not worked around via massive package over-selection like
it's the case now. Today it's gotten to the point that if one wanted to
really untangle the mess it'd take at least two or three FC iterations
IMHO.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050123/65dedbe1/attachment.sig>