Home_greyopenFATE - openSUSE feature tracking > #301175
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Update Messages Handling

Feature state

openSUSE-10.2
Rejected Information
openSUSE-10.3
Rejected Information
openSUSE-11.2
Done

Description

During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails.

In general, it is not possible to send emails from rpm install scripts. Most cases could be handled by the release notes but there are cases that cannot and we need a better solution to present this, especially since many people to not read the local emails.

Relations

Discussion


icons/user_comment.png H. V. wrote: (11 years ago)

Cleanup the messages and readd the features we lost with the removal of SUSEPlugger to zen-updater or whatever?

icons/user_comment.png D. M. wrote: (11 years ago)

Current patches offer the message feature, so you could basically offer that package as a patch.
If that is not sufficient, I propose something:
We add a /var/spool/zypp-messages or something, and a binary which rpm spec call to inject messages.
The zypp backend of the applet, check the spool in every check and use knotify to notifiy the user.
I am only missing, where does the current rpm inject the messages to?

icons/user_comment.png E. P. wrote: (11 years ago)

Andreas: any comments on the proposed solutions?

icons/user_comment.png D. M. wrote: (10 years ago)

A proposal for normal packages:

Create a dbus/dcop interface both applets implement.

  • create a /usr/sbin/update-messsage wrapper that allows rpms to send a message.
  • the wrapper sends a dcop/dbus message to the applets, which in turn show a passive popup?
Other ideas?

icons/user_comment.png E. P. wrote: (10 years ago)

Coolo, should we go ahead with the proposed solution and make a late feature admission request?

icons/user_comment.png S. K. wrote: (10 years ago)

No, this requires documentation changes I'm not willing to accept. So I rather stay with the status quo ;(

icons/user_comment.png E. P. wrote: (10 years ago)

Then please reject for 10.3.

icons/user_comment.png D. M. wrote: (9 years ago)

Please reject for 11.0. All resources allocated with mandatory features already.

icons/user_comment.png D. M. wrote: (9 years ago)

Please reject for SLE11/11.1. All resources allocated with mandatory features already.

icons/user_comment.png M. M. wrote: (9 years ago)

This was promised as "will be done" to the Maintenance Department.

Mark it Mandatory for SP1.

icons/user_comment.png F. L. wrote: (9 years ago)

please note, any solution must not break "RPM only" compatibility - meaning these should be notification messages, not scripts used in any event to finish configuration or to cause "side effects" of any kind.

icons/user_comment.png F. L. wrote: (9 years ago)

I disagree with the rationale that users don't read local mail. An admin should have that local mail forwarded, and I think we ought to facilitate configuring the forwarding even to other machines.

I think that may have more success than popups... at least for Enterprise customers. For community use, sure, popups are helpful (as init 5 is more likely :-)

icons/user_comment.png S. K. wrote: (9 years ago)

but who would send these mails if rpm is the only vehicle we can be sure of. We don't want packages to send mails.

icons/user_comment.png M. A. wrote: (8 years ago)

That's the zypp.conf option I'd like to introduce for this feature:

## 
## Command to be invoked to send update messages.
##
## Packages may leave an update message file in {update.messagesdir}.
## At the end of each commit, zypp collects those messages and may send
## a notification to the user.
##
## zypp will prepare the update messages according to the selected
## content format and pipe the content to the command.
##
## Format:
## single - For each update message invoke the command and send
## the message.
## none - For each update message invoke the command but don't
## use a pipe to send any data. You probably want to pass
## the message file on the commandline using %P (see
## Substitutions).
## digest - Single invocation of the command, sending the path
## names of all update message. One per line.
## bulk - Single invocation of the command, sending the
## concatenated content of all update messages, separated
## by Ctrl-L.
##
## Substitutions:
## %p - package identification (name-version-release.arch)
## %P - full path to the update message file
##
## Valid values: The value is specified as "format | command".
## An empty value will turn off any notification.
##
## Examples: single | mail -s 'Update message from %p' root
## none | my-send-script -f %P
##
## Default value: single | /usr/lib/zypp/notify-message -p %p
##
# update.messages.notify = single | /usr/lib/zypp/notify-message -p %p
icons/user_comment.png M. A. wrote: (8 years ago)

The libzypp part seems to be
done with libzypp-6.18.0 (for openSUSE 11.2). The /usr/lib/zypp/notify-message script, which gets invoked per default, sends mail with subject
[zypp-notify-message] packagename-version.arch
to root. The feature can be configured/disabled in /etc/zypp.conf.

The list of update message files is also returned via ZYppCommitResult, so zypper/UI could write a note, or even offer to display them if we want that too. And we could also think about sending the config file diffs we create via this feature.

icons/user_comment.png J. K. wrote: (8 years ago)

Zypper 1.2.11 now shows a list of packages which wrote notifications, and offers to view them all in pager. Submitting the package in few minutes.

icons/user_comment.png K. E. wrote: (8 years ago)

A proper summary suitable for doc purposes is missing. We are not that much interested in implementation details, but how the user will ssee the implementation.

I guess this notification system will also for are package installation time (not only in the update case)?

If the user updates the system (or just packages) using YaST, will YaST display these notifications? Is this a one-time-opportunity, or is it possible to display these messages later again?

Last change: 8 years ago
Voting
Score: 0
  • Negative: 1
  • Neutral: 0
  • Positive: 1
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint