Re: RPM needs to go on a diet.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Havoc Pennington wrote:

On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote:


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 wouldn't exactly describe this as a "simple question" ;-)


Like i said half heartedly. And im not proposing this be a default operation but possible a mode of operation. Like the work on yum interactive that is going on right now.

The right approach is to just have a default garbage collection policy,
and for the 0.25% or less of the world that wants something else have a
config file where you can disable kernel GC entirely or pin certain
versions so they won't be removed.


I agree. A good default behavior is in perfect line with my suggestion. Essentially i am proposing to have a system where the default operation satisfies most of the user base and you only enter interactive mode (in CLI or GUI) if you try a transaction and you dont like the suggestions or would like to know more options (like adding plugins to newly installed apps or choosing which 1 of the two applications that provide the same functionality (firefox, mozilla). To be prefectly clear i am not trying to punt the decision to the user. I wanted a good default option (current plus highest sounds best) with the ability for a user to make decisions should they desire to do so in this and other cases like i mentioned. The kernel argument isnt a huge one for this interactive mode. It just seemed to be one more piece that lended slightly to the argument for me. And im not proposing the interactive mode as default behavior but i think that there are a lot of issues like unknown plugins (to the user), and plugins that require either X or Y and i dont know how they are resolved at this time and i thought that it might be nice to try to flesh out a unified solution that simplifies the process using package management tools instead of cron jobs and scripts. Many new users to fedora dont know they need to download plugins to enhance programs and i was trying to give them a way to "discover" fedora using the same tool that they use to manage the installation of the new application.

-mf


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux