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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
