No error message when a package install fails in %pre in rpmdrake and gurpmi

[Jeff Johnson]

%pre failures mapped through "best effort" are still surprising

[Zen25000 (zen25000)]

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.

[Thierry-vignaud (thierry-vignaud)]

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.

[Pascal Terjan (pterjan42)]

Well, for the pre the installation fails, I would expect rpm to report that the transaction failed (maybe not on which package and why).

[Ahmad Samir (ahmad.samir)]

(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.

[Marja11 (marja11)]

ping?

[Grigory (grigory-redhat-bugs)]

Created attachment 534207
specfile for the first package

Description of problem:
1) Package2 requires Package1
2) Package1 has an error in the %pre scriptlet
3) Installation of the pair of packages should fail (I believe), but it just ignores an error in pkg1 and installs pkg2

Version-Release number of selected component (if applicable):
rpm-4.9.1.2-1.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
$ cd ~/rpmbuild/SPECS/
$ rpmbuild -ba pkg1.spec pkg2.spec
$ sudo rpm -ihv ../RPMS/noarch/{pkg2-2-2,pkg1-1-1}.noarch.rpm
Preparing... ########################################### [100%]
error: %pre(pkg1-1-1.noarch) scriptlet failed, exit status 1
error: pkg1-1-1.noarch: install failed
   1:pkg2 ########################################### [ 50%]
$ rpm -q pkg1 pkg2
package pkg1 is not installed
pkg2-2-2.noarch
$ rpm -q --requires pkg2
pkg1

Actual results:
Package2 is installed

Expected results:
Installation of Package2 failed

Additional info:
The same is in CentOS-5.7 (rpm-4.4.2.3-22.el5_7.2).

[Grigory (grigory-redhat-bugs)]

Created attachment 534208
specfile for the second package

[Panu (panu-redhat-bugs)]

Yes, this is expected and has always been the case, rpm doesn't even try to track dependencies during the transaction. There must be a dozen duplicates of this around bugzilla :)

While the "right thing to do" looks (and would be) easyish to achieve in a trivial case like the example here, things get ugly real fast when the transactions become more complex. Such as packages with dependency loops, eg pkg1 and pkg2 that depend on each other, installation of first one succeeds but the latter fails -> there's no way to truly undo what the installation of the first one might have done (through scripts etc). And then consider dependency loops consisting of large number of packages (IIRC Centos 5.x has dep loops involving > 20 packages in the core package set) and what should happen if one of them fails... etc.

"Right thing" being not always achievable doesn't have to mean we couldn't do it when it's possible though.

[Akira (akira-redhat-bugs)]

I'm facing same issue at the summary but not on f15 nor f16. it works fine for me, but not on rawhide. it doesn't explicitly say any failure because it has "exit 0" at the end according to https://fedoraproject.org/wiki/Packaging/UsersAndGroups

Version-Release number of selected component (if applicable):
rpm-4.9.1.2-3.fc17.x86_64

How reproducible:
always

Steps to Reproduce:
1. yum install Canna

Actual results:
many warnings like:

warning: user canna does not exist - using root

appears.

Expected results:
no warnings

Additional info:
As I said, it works on f16 and the issue happens on rawhide only with the same package. for reference, the spec file is:
http://pkgs.fedoraproject.org/gitweb/?p=Canna.git;a=blob;f=Canna.spec;h=cda2111032f5996552c8e411e31cb57c7f682438;hb=HEAD#l269

Also just tried to get rid of "exit 0" didn't help. no errors. so it looks like rpm just ignores %pre script in rawhide.

[Akira (akira-redhat-bugs)]

Hmm, guess I better file a new one...

[Panu (panu-redhat-bugs)]

Yes that Canna thing is a totally different issue. Such issues are typically missing %pre dependencies in the package in question, OR some other breakage. For example in this case, if getent/groupadd/useradd happened to be broken in rawhide (I dunno, but its one possibility), there's *zero* rpm can do about it.

[Grigory (grigory-redhat-bugs)]

Panu, thank you for the explanation.
What if I use "rpm -q pkg1" in pkg2's %pre scriptlet? It seems to work, i.e. aborts installation on the pkg1 failure (excluding failure of upgrading of pkg1).

[Panu (panu-redhat-bugs)]

Rpm queries (or other uses) from within scriptlets is not a good idea. It works most of the time, but there are situations where it WILL break and there's no way for the package to know when that happens.

A much safer choice is to for example test for file existence: if a file from pkg1 doesn't exist at pkg2's %pre, pkg1 quite obviously isn't installed at that point.

[Grigory (grigory-redhat-bugs)]

(In reply to comment #7)
> A much safer choice is to for example test for file existence: if a file from
> pkg1 doesn't exist at pkg2's %pre, pkg1 quite obviously isn't installed at that
> point.

Right! Thanks again.

[Jeff Johnson (n3npq)]

tracked at https://bugs.launchpad.net/rpm/+bug/913221

[Marja11 (marja11)]

3 monthly ping

[Marja11 (marja11)]

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

[Zen25000 (zen25000)]

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 ;)

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Zen25000 (zen25000)]

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?

[Thierry-vignaud (thierry-vignaud)]

We don't want a random package to randomly abort in its %pre, thus breaking urpmi flow.
That's a bad idea