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]