Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 83476 - [RFE] Notification specifies available packages but should also specify why
Summary: [RFE] Notification specifies available packages but should also specify why
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rhn-applet
Version: 8.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-04 19:26 UTC by Michael Lee Yohe
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-02-04 23:35:22 UTC


Attachments (Terms of Use)

Description Michael Lee Yohe 2003-02-04 19:26:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030102

Description of problem:
Since the information sent to rhn-applet-gui contains the packages available,
the errata or security advisor information would be nice to see without having
to start up2date.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  see description
2.
3.
    

Additional info:

Comment 1 Daniel Veillard 2003-02-04 23:35:22 UTC
Well that's not possible without duplicating up2date capabilities in
the applet. The code of the applet is big enough. Why don't you want
to start up2date ? That seems the real question to me, but I don't see
any compelling point justifying duplicating code.

Daniel

Comment 2 Michael Lee Yohe 2003-02-05 15:19:23 UTC
You're indeed correct - the applet _is_ big enough considering its memory
requirements.

 2507 myohe     15   0 16208  14M 10380 S     0.7  1.9   0:28 rhn-applet-gui

I don't see how you would be duplicating up2date capabilities - you're simply
informing the user what packages are available (already done) and the
notifications with the update (not done).  For my Pentium 4 2.4GHz workstation,
invoking up2date is not really a problem - it only takes about 15 seconds to get
to the point where I can read what is actually "fixed" by the update.  For my
other P2-400MHz workstation, it takes a pretty good bit of time (definitely more
than 15 seconds).

The point being was that rhn-applet-gui obviously knows _something_ about the
update since it's displaying information for the end user.  I didn't realize it
was going to make things difficult/complicated to simply download the advisory
information along with the packages that were available for update.

*shrug*




Comment 3 Daniel Veillard 2003-02-05 15:36:08 UTC
> I don't see how you would be duplicating up2date capabilities

  Those are offered by up2date. That uses DIFFERENT interfaces and
code to get those informations tnat the ones used to provide the 
current check in the applet. The up2date check MUST STAY LIGHT in term of
data exchange and code involved. What you are asking is to add this code
which is present in up2date and put it in the applet checking path
and I tell you I will not duplicate that code nor increase the pressure
on the RHN servers needed to extract those informations.

  The applet gives a quick check status, period. The full operational
code is in up2date. I will not migrate those advanced up2date capabilities
in the applet. That's not it's role.

Daniel


Note You need to log in before you can comment on or make changes to this bug.