status of up2date and rhn-applet

[Jeremy Katz]

On Fri, 2005-11-25 at 11:29 +0100, Rudolf Kastl wrote:
> 2005/11/24, Jesse Keating <jkeating at j2solutions.net>:
> > 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