RPM needs to go on a diet.

Michael Favia michael.favia at insitesinc.com
Thu Feb 17 20:14:28 UTC 2005


Jeff Spaleta wrote:

>On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson <n3npq at nc.rr.com> 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.

or

Mplayer-plugin requires either mozilla or firefox to be present which 
would you like to install?
  Mozilla (X Megs)
  Firefox (X Megs)

or

The followng plugins depend on gaim but are not installed woudl you like 
to add these features?

I am only halfheartedly trying to make these make sense and the last one 
might require a rpm flag or something, but the functioanlity would be 
appreciated by a great numebr of users i think. Managing the changes so 
that users arent overwhelmed with options and confused is the key to 
adding this functionality sanely but i think that it can be done and 
should be done eventually. Obvioulsy a Yum based GUI tool would handle 
this type of interactivity more adeptly becuase of the multiple 
selections that are made by the user. If there is genuine interest id be 
happy to mockup an User interaction model that might help ease some of 
these and other pains while providing the user with a simple and useful 
software upgrade interface. IMO as the number of packages continue to 
increase we need to be able to provide users with this type of 
information instead otf the raw data we are asking them to sort through 
right now.

-mf




More information about the fedora-devel-list mailing list