2005/11/26, Jeremy Katz <katzj@xxxxxxxxxx>: > 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. hmm. that means that there are 2 different uis regarding package management? i am not sure if it makes too much sense to split up a "package installer" and a "package updater" cause both are just uis for yum. Handling the whole packagemanagement from (maybe even one) UI would be great. Question there is how system-config-package will work actually. is it going to prompt for the cds? what happens if the system is already updated and installing from cds doesent work really? is there an option to kinda install "updated packages" ? will groups from extras or 3rd party repos also be listed? (dynamically reading and merging groups via yum from repos?!). > > > 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? use case: i am working alot with various repositorys, different configurations etc... its useful for advanced users, including my own repo. actually yum has this feature aswell because its a cli option. same use cases basically as for the cli option. > > > 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. use case: broken rawhide installs/updates on x86_64 e.g. ;)) > > > 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. thats great. > > > 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 :-) yup, might be helpful. > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
