On Thu, 2004-04-22 at 13:33 -0400, Havoc Pennington wrote: > On Thu, 2004-04-22 at 09:43, Gene C. wrote: > > > > Should kdenetwork be split so kmail is not included but instead moved to > > Extras? This has to be a management nightmare. > > > > For end-user apps (i.e. those in the menus), it will almost always be > desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we > should be syncing the name of the package displayed in the package tool > (including translations) with the .desktop file name. Or even making > package management happen in terms of .desktop files. From a single-user > standpoint, "menu editing" (at least in terms of add/remove items) and > "package management" really have no reason to be different. > > The ideal user experience might be to effectively refcount each RPM by > the number of users that have it in their menus, and when nobody has the > item in their menus the package gets removed. And similarly you'd > install a package by choosing what items to add to your menus. Unclear > if there's a sane way to implement this, but this is a nice way for a > desktop user to see things. > > Obviously it only works for desktop-app type of packages. You need > another approach to deal with servers, though you could perhaps imagine > a similar approach (when you enable the service, it automatically gets > the required packages and punches the firewall to make the service go). > > Also, even if package add/remove were combined with menu editing, you > still need an "update" or "get patches" kind of UI... though judging by > the number of Windows viruses out there, perhaps the default should be > to run this thing automatically every night unless the user opts out ;-) > > Anyway, we really should think about the issue much more broadly and not > assume that the task at hand is "write a single tool that does package > management." How can we get it smoothly integrated into the desktop? > Maybe there are multiple tools for different tasks or kinds of user. > > There are related problems too, such as making it really easy for third > parties to provide a set of RPMs with comps file on a CD or in an http > directory, and handle that really nicely with an install wizard. > > Just some brainstorm ideas. Let's start with what the user should see > though, and then figure out how to implement our closest approximation. > > Havoc That sounds soo nice for the end user. But what about me? I've been using linux since 1996. I was 12 by then and I'm not sure I'm ready for such radical changes. I just love being in control of things. First I WANT to be able to select the rpm packages one-by-one, whether it's in anaconda or system-config-packages, we should not forget those users which want to be in control. It's nice to have an easier way, but lets not give up the power of rpm.
