Bug 83476 - [RFE] Notification specifies available packages but should also specify why
[RFE] Notification specifies available packages but should also specify why
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rhn-applet (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-04 14:26 EST by Michael Lee Yohe
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-04 18:35:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Lee Yohe 2003-02-04 14:26:22 EST
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 18:35:22 EST
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 10:19:23 EST
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 10:36:08 EST
> 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.