| Summary: | No error message when a package install fails in %pre in rpmdrake and gurpmi | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Barry Jackson <zen25000> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | marja11, n3npq, pterjan |
| Version: | Cauldron | Keywords: | Triaged |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | urpmi | CVE: | |
| Status comment: | |||
|
Description
Barry Jackson
2011-06-07 15:56:19 CEST
Ahmad Samir
2011-06-07 17:45:45 CEST
Summary:
No error message when a package install fails in %pre =>
No error message when a package install fails in %pre in rpmdrake and gurpmi
Ahmad Samir
2011-06-07 17:46:01 CEST
CC:
(none) =>
pterjan I'm not sure rpm actually tell us about such errors. Eg: I/O errors used to be (still are?) silently ignored. It's somewhat visible with urpmi since rpm actually writes error message on the console but urpmi is actually unaware of that. Well, for the pre the installation fails, I would expect rpm to report that the transaction failed (maybe not on which package and why). (In reply to comment #2) > Well, for the pre the installation fails, I would expect rpm to report that the > transaction failed (maybe not on which package and why). Yes, at least giving some sign to the user that it failed. 3 monthly ping Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja Keywords:
(none) =>
NEEDINFO It's at times like this when I wish that I had not been so enthusiastic in reporting this. :( It was actually aimed at the get-skype package that I was working on at the time which would die quietly if the download failed. Since no one else has complained about this I think it reasonable to consider it a candidate for a WONTFIX as I am sure we have more important issues to deal with. Closing as RESOLVED WONTFIX Please feel free to re-open ;) Status:
NEW =>
RESOLVED I'm re-opening as I have now another need for this to work. In an attempt to stop grub2 updates from happening if /boot/grub2/drakboot.conf does not exist I tested this: %pre if [ $1 -eq 2 ] && ![ -e /boot/grub2/drakboot.conf ]; then echo -e "Cannot update grub2 without a known target boot drive \n \ please create /boot/grub2/drakboot.conf containing boot=/dev/sdX \n \ and try to update again" exit 1 fi The result: [root@jackodesktop grub2]# rpm -qa|grep grub2 grub2-mageia4-theme-dejavu-1.0-1.mga4 grub2-2.00-58.mga4 [root@jackodesktop grub2]# urpmi --auto-update medium "Extra Release (zm-repo46)" is up-to-date medium "Core Release (zm-repo1)" is up-to-date medium "Core Updates (zm-repo3)" is up-to-date medium "Nonfree Release (zm-repo11)" is up-to-date medium "Nonfree Updates (zm-repo13)" is up-to-date medium "Tainted Release (zm-repo21)" is up-to-date medium "Tainted Updates (zm-repo23)" is up-to-date medium "Core 32bit Release (zm-repo31)" is up-to-date medium "Core 32bit Updates (zm-repo32)" is up-to-date medium "Nonfree 32bit Release (zm-repo36)" is up-to-date medium "Nonfree 32bit Updates (zm-repo37)" is up-to-date medium "Tainted 32bit Release (zm-repo41)" is up-to-date medium "Tainted 32bit Updates (zm-repo42)" is up-to-date To satisfy dependencies, the following package is going to be installed: Package Version Release Arch (medium "Extra Release (zm-repo46)") grub2 2.00 59.mga4 x86_64 16B of disk space will be freed. 2MB of packages will be retrieved. Proceed with the installation of one package? (Y/n) y [root@jackodesktop grub2]# rpm -q grub2 grub2-2.00-58.mga4 [root@jackodesktop grub2]# Nothing reported by urpmi at all (the package was already in cache so no download shown) How can I get this message to be displayed in both GUI and urpmi when the install fails? Status:
RESOLVED =>
REOPENED
Samuel Verschelde
2015-05-03 11:32:18 CEST
Keywords:
NEEDINFO =>
Triaged We don't want a random package to randomly abort in its %pre, thus breaking urpmi flow. That's a bad idea Status:
REOPENED =>
RESOLVED |