Hi!
I justed noticed this:
bugzilla@redhat.com schrieb:
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: tripwire - IDS https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864
------- Additional Comments From zing@fastmail.fm 2006-10-19 11:08 EST ------- please don't spam the rpm installation with a cat of the README.RPM file.
I'd say a note in the %description pointing the user to the /path/to/README.RPM is a fine place for that.
At most, _maybe_ a one line echo of the /path/to/README.RPM... and even that doesn't really sit to well with me...
I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff?
Cu thl
Thorsten Leemhuis (fedora@leemhuis.info) said:
I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff?
Honestly, I thought it was already part of the policies. %pre/%post can not be interactive.
Bill
"BN" == Bill Nottingham notting@redhat.com writes:
BN> Honestly, I thought it was already part of the BN> policies. %pre/%post can not be interactive.
I thought "interactive" meant "accepting or expecting input". I'm not sure that simple display of text is also forbidden.
- J<
On Thu, 19 Oct 2006 14:27:16 -0500, Jason L Tibbitts III wrote:
"BN" == Bill Nottingham notting@redhat.com writes:
BN> Honestly, I thought it was already part of the BN> policies. %pre/%post can not be interactive.
I thought "interactive" meant "accepting or expecting input". I'm not sure that simple display of text is also forbidden.
Then let's make it "scriptlets can neither be interactive nor informative".
You cannot expect GUI tools to capture stdout/stderr output and display it during or after installation/upgrade/removal of a package. In other words, output is lost (if not logged in any place, which would be non-obvious).
Trying to give post-install instructions to a user via scriptlets is bad habit. Should happen in README %doc files instead.
Aloas,
On Thursday 19 October 2006 21:47, Michael Schwendt wrote:
Trying to give post-install instructions to a user via scriptlets is bad habit. Should happen in README %doc files instead.
I want to propose to send post-install instrutions via mail to the root user additionally, this way one needs not to look into the documentation for every installed package but gets every information collected in his inbox.
Regards, Till
On Thu, 2006-10-19 at 22:25 +0200, Till Maas wrote:
Aloas,
On Thursday 19 October 2006 21:47, Michael Schwendt wrote:
Trying to give post-install instructions to a user via scriptlets is bad habit. Should happen in README %doc files instead.
I want to propose to send post-install instrutions via mail to the root user additionally, this way one needs not to look into the documentation for every installed package but gets every information collected in his inbox.
Bad idea. I have 2176 packages installed so potentially, I'd have 2176 emails awaiting me when I install a fresh box. Once enough packages start doing this, I won't be wading through my INBOX to find the information....
$ rpm -ql foo $ less /usr/share/doc/foo-1.0/README
would still be my method of finding documentation.
-Toshio
On Thu, Oct 19, 2006 at 12:38:25PM -0400, Bill Nottingham wrote:
Thorsten Leemhuis (fedora@leemhuis.info) said:
I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff?
Yes. But that means filing a bug against glibc for visibly restarting ssh for example.
Honestly, I thought it was already part of the policies. %pre/%post can not be interactive.
I think this is already strongly deprecated at the pure rpm level. We could add a note on this in the guide, but it shouldn't suggest we really ever had another choice. :)
Just as a side note: It's been a debate for several years now that dpkg allows licenses to be displayed in non-batch mode, and that rpm only has batch mode and thus no means for licenses to be displayed. Not that it's actually a drawback.
In general most higher level rpm tool assume output on stderr/stdout from rpm packages to be an error and present it that way.
On Fri, 2006-10-20 at 01:38 +0200, Axel Thimm wrote:
On Thu, Oct 19, 2006 at 12:38:25PM -0400, Bill Nottingham wrote:
Thorsten Leemhuis (fedora@leemhuis.info) said:
I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff?
Yes. But that means filing a bug against glibc for visibly restarting ssh for example.
Honestly, I thought it was already part of the policies. %pre/%post can not be interactive.
I think this is already strongly deprecated at the pure rpm level. We could add a note on this in the guide, but it shouldn't suggest we really ever had another choice. :)
Just as a side note: It's been a debate for several years now that dpkg allows licenses to be displayed in non-batch mode, and that rpm only has batch mode and thus no means for licenses to be displayed. Not that it's actually a drawback.
In general most higher level rpm tool assume output on stderr/stdout from rpm packages to be an error and present it that way.
only b/c we have no other choice.
If we could get rpm to be silent and have all of the messages (stderr or stdout) be presented back to us as part of the callback I think most of us would be quite happy. If only b/c it would mean we would then have the option of echoing it back to the user, saving it to a log or both.
-sv
seth vidal wrote :
If we could get rpm to be silent and have all of the messages (stderr or stdout) be presented back to us as part of the callback I think most of us would be quite happy. If only b/c it would mean we would then have the option of echoing it back to the user, saving it to a log or both.
I couldn't agree more. I find it plain silly to almost always have to execute "foo args &>/dev/null || :" in scriplets, when getting the output of the command as well as knowing if it actually failed or succeeded can be interesting information. If we could have a log file of rpm operations output, it would be really great.
*BUT* this does mean breaking backwards compatibility in many cases (i.e. having failing scriplets leave duplicate packages in the rpmdb).
Matthias
packaging@lists.fedoraproject.org