Bug 1670 - No error message when a package install fails in %pre in rpmdrake and gurpmi
Summary: No error message when a package install fails in %pre in rpmdrake and gurpmi
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2011-06-07 15:56 CEST by Barry Jackson
Modified: 2015-05-03 16:17 CEST (History)
3 users (show)

See Also:
Source RPM: urpmi
CVE:
Status comment:


Attachments

Description Barry Jackson 2011-06-07 15:56:19 CEST
Description of problem:
In both rpmdrake and gurpmi there is no error visible to the user indicating that the instllation of a package has failed in %pre.

In gurpmi the "Installing..." dialog just closes without any error, leading the user to think that the installation completed.

It's not so bad in rpmdrake as the orange download icon has not turned green and the check box is still unchecked, but it still should indicate that there was a problem and give some guidance.

I am currently developing a package which involves a download to complete in %pre - if this fails the user needs to know about it and not be left guessing.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a package with "exit 1" in %pre
2. Click on the package to install it with gurpmi
3. Enter password
4. Installing dialog appears for a while then closes
5. No error message.

In rpmdrake :-
1. Add the package to a local repo
2. Try to install it with the GUI
3. Install looks normal
4. Then reverts to GUI in uninstalled state
5. No error message.
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
Assignee: bugsquad => thierry.vignaud

Comment 1 Thierry Vignaud 2011-06-14 15:29:02 CEST
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.
Comment 2 Pascal Terjan 2011-06-14 15:41:50 CEST
Well, for the pre the installation fails, I would expect rpm to report that the transaction failed (maybe not on which package and why).
Comment 3 Ahmad Samir 2011-06-14 18:47:17 CEST
(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.
Comment 4 Marja Van Waes 2011-10-20 09:30:09 CEST
ping?

CC: (none) => marja11

Comment 5 Jeff Johnson 2012-01-07 19:43:39 CET
tracked at https://bugs.launchpad.net/rpm/+bug/913221

CC: (none) => n3npq

Comment 6 Marja Van Waes 2012-04-21 20:40:24 CEST
3 monthly ping
Comment 7 Marja Van Waes 2012-05-26 13:09:59 CEST
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

Comment 8 Barry Jackson 2012-06-14 21:54:09 CEST
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
Resolution: (none) => WONTFIX

Comment 9 Barry Jackson 2014-02-08 00:32:41 CET
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
Resolution: WONTFIX => (none)

Samuel Verschelde 2015-05-03 11:32:18 CEST

Keywords: NEEDINFO => Triaged
Source RPM: urpmi-6.40-9.mga1.src.rpm => urpmi

Comment 10 Thierry Vignaud 2015-05-03 16:17:31 CEST
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
Resolution: (none) => WONTFIX


Note You need to log in before you can comment on or make changes to this bug.