On Fri, 2005-11-25 at 11:29 +0100, Rudolf Kastl wrote: > 2005/11/24, Jesse Keating <jkeating@xxxxxxxxxxxxxxx>: > > On Thu, 2005-11-24 at 09:23 +0100, Joachim Frieben wrote: > > > "up2date-gnome" is by far the most usable update tool to date. > > > "pup" is really not on par in any respect. I really have no > > > idea why people spent time on that one. The best would be to > > > simply remove it. I do really hope that "up2date-gnome" will > > > remain in the distro. If it uses "yum" under the hood that's > > > ok. Concerning "rhn-applet" your right: it is already unusable > > > in FC4. No reason to drop it though. It should get fixed unless > > > somebody comes up with an alternative shiny new update notifier. > > > > > > > Would you care to give some constructive feed back as to why you find > > pup so intolerable in it's first release version? What about > > up2date-gnome did you like and would like to see in the standalone pup? > Feature Requests for pup: > > 1. Handling of Packagegroups for Groupwise updating pup is going to be a very simple update UI -- group handling is more of system-config-package's area and the plan is for it to be enhanced to sit on top of yum as well. That's actually my plan of what I'm mostly working on next week. > 2. Notification applet (maybe as external application may as internal > feature... guess external would be preferred) Yeah, some form of notification on new updates is definitely needed, although exactly how we want to do that is currently a bit of an open question. The big thing is that we want to avoid some of the memory usage "problems" that people perceived with rhn-applet > 3. Repository Handling from UI (i liked the up2date behaviour to > selectively enable and disable repos) I'm not against this (the glade file actually has the button to bring up such a dialog, it's just not currently enabled), but I'm mostly curious what the use case is for it. Why would you not want to get the available updates for all configured repositories? I can see wanting to configure what repositories you use for getting software when installing new stuff, but what's the use case for doing it while updating? > 4. selectivly exluding packages by gui (clickable list with checkbox > buttons maybe?) You can currently exclude based on src.rpm -- hopefully we'll get metadata regarding update advisories available before FC5's release so that can be used as the granularity instead. This is far more likely to allow things to just work than selecting individual subpackages (and/or architectures) of packages due to the interdependent nature. > 5. all of the above stuff saveable into yum config files to have a > consistent environment. Anything we do as far repository changing will definitely involve just modifying the existing yum config files, so no worries there. In fact, everything done now in pup should be following exactly the configuration used by yum on the command-line. > while i think that most of above suggestions arent really necassery > for even an 1.0 release of the software and while i additionally think > that some of the above stuff should probably go under an "advanced" > tab, i think that some of the above mentioned stuff can be helpful to > make package updates properly manageable from gui. Hope this helps a bit in giving some idea of where we're going. I need to make an effort this weekend to sit down and actually write up at least some basic stuff to be able to point to as some of these questions have come up often enough that I want to be able to just point to a web page with the answers :-) Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
