On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote: >Jeff Spaleta wrote: > >>On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson <n3npq@xxxxxxxxx> wrote: >> >> >>>Or have every possible bleeping kernel already pre-installed and never >>>remove anything. >>>Unfortunately, that exercises known deficiencies with both rpm and >>>hardlinks, and is >>>slower than optimal, so take valium and be patient. >>> >>> >> >> >>The question becomes... can someone expose reasonable sane default >>behavior of some tool to do old kernel pruning... to avoid normal >>fedora users from encountering these deficiencies when you have 17 or >>so update kernels installed. >> >> >For me this issue and others (plugins, kernel modules, >missingok/optional features) seem to bolster the claim for a more >interactive Yum or at least yum mode. A yum that poses a few simple >question to the user like: > >You have 7 kernels installed we recommend that you keep the number of >kernels installed concurrently fewer than 3 would you like to remove >some of them? > Yes all but the most recent 3. > No keep your grimy hands off my kernels. I'd much, much rather just see the proper and most correct behavior be added to Yum, instead of punting the issue and making the user handle it. Especially given the number of users that don't know, or want to know, the correct answer. Really, there's only two kernels you'd ever need, aside from specialty cases that normal users don't have to worry about. Those kernels are the currently running kernel, and the kernel you plan on getting on your next boot (i.e., the newest kernel). Simply making that the default behavior, with options or features for more advanced users to pin kernels or disable the behavior, would be far more beneficial for the average user, as well as greatly simplify the life of yum front-end and library users. > >or > >Mplayer-plugin requires either mozilla or firefox to be present which >would you like to install? > Mozilla (X Megs) > Firefox (X Megs) Same deal here. Better to just come up with a policy for picking one automatically. If a user is advanced enough to know which they want, they can install it explicitly with the plugin/add-on. > >or > >The followng plugins depend on gaim but are not installed woudl you like >to add these features? Now this is somewhat of a different issue. Being able to mark a package as an "add-on" to another could *really* help user-oriented package management tools. For example, if I open up the Application Manager, I *only* expect to see applications - not plugins or libraries or anything else. If I click on GAIM, it could then display a list of plugin package that are installed or available. By default, though, when initially installing GAIM, I dont' think you should ask the user, unless the user has explicitly stated that they want the control (i.e., a "confirm suggested packages" option that is off by default). Something like a "Suggests" field might work - those are the packages that GAIM doesn't need, but recommends are installed with it, which would be default behavior. -- Sean Middleditch <elanthis@xxxxxxxxxxxxxxx>
