Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 458311

Summary:	RFE: email notification for new updates only.
Product:	Red Hat Enterprise Linux 5	Reporter:	Aleksey Nogin <aleksey>
Component:	yum-updatesd	Assignee:	James Antill <james.antill>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	low	Docs Contact:
Priority:	medium
Version:	5.5	CC:	bgollahe, james.antill, syeghiay
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-30 14:34:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Aleksey Nogin 2008-08-07 15:38:26 UTC

With do_update = no and emit_via = email, once some updates become available, yum-updatesd starts generates a notification email on every single run. I come back to my email in the morning and see a large number of identical yum-updatesd messages, which is annoying. If for some reason I do not want to install the updates right away, it keeps bugging me.

If would be really nice to have an option of only getting an email when *new* updates are available - that is, when some of the available updates were not yet included in a previous notification email.

Comment 1 James Antill 2008-08-07 16:34:03 UTC

 Currently yum-updatesd doesn't store anything itself, this kind of feature would require that we store the "current updates" and diff it on the next run.

 This is unlikely to happen, esp. if it doesn't happen upstream first. I'll move this to rawhide ... but I wouldn't expect a quick resolution.

Comment 2 Jeremy Katz 2008-08-08 00:03:19 UTC

This is working exactly as its intended too.  Keeping some sort of state would basically entail leaving the rpmdb/yum state locked or serializing it in some way, which really isn't that interesting.

Comment 3 Aleksey Nogin 2008-08-08 16:18:58 UTC

Well, even if it's working as "intended", and improving it is not "interesting", this results in quite unpleasant end-user experience, including for paying RHEL users like me. I get yum-updatesd notifications from several different machines (they have different sets of packages installed, different channel subscription, etc, so I need separate notifications) and being "mailbomed" by all of them every time a common update is posted to RHN is quite annoying. Please reconsider the "WONTFIX".

P.S. IMHO, keeping state in a small text file in /var/cache/yum would not be a big deal.

Comment 4 James Antill 2008-08-08 16:44:53 UTC

 This BZ wasn't attached to any support request, which is why I moved it to Fedora.

 If you raise the request through the support channels you might get a different answer than the current one, even if _eventually_ it'll get back to me with a different BZ.

Comment 5 Aleksey Nogin 2008-08-08 17:25:38 UTC

OK, filed Service Request 1849028 on this.

Comment 6 Aleksey Nogin 2010-09-02 03:57:51 UTC

Still a big annoyance in RHEL 5.5 (especially when email notifications are enabled on several machines). Any chance this could be revisited?

Comment 8 Libor Miksik 2012-10-25 12:30:22 UTC

Thank you for submitting this issue for consideration. Red Hat Enterprise Linux 5 has reached the end of Production 1 Phase of its Life Cycle.  Red Hat does not plan to incorporate the suggested capability in a future Red Hat Enterprise Linux 5 minor release. If you would like Red  Hat to re-consider this feature request and the requested functionality is not currently in Red Hat Enterprise Linux 6, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.