On Feb 18, 2011, at 10:28 AM, Mircea Lemnaru wrote:
> Hi all,
> I having some issues with a project that I am working on, in short , the user installs 2 rpm’s , using the command say: “rpm –I pkg1 pkg2” . The first package contains a post install script that fails , this results in an general error / non zero return code so my wrapper over the rpm command assumes the command failed and the rpms did not get successfully installed, but it turns out that if I query the database after the command ended , the packages show up as installed , no mention of the failed post install script.
What version of RPM? This sounds like its _NOT_ the ACID behavior
that is implemented in rpm-5.3.x, where the package header registered
in an rpmdb is part of a transaction, and will be backed out, not left
in an rpmdb, if/when a package scriptlet fails.
Please note that there's 2 other parts of what is known as
Transactionally Protected Package Management
that are _NOT_ turned on yet, and so the files installed are the files installed
by the package with the failing %post script. But the database registration SHOULD
be fully functional now.
But otherwise the behavior is as expected.
package with a failing %post will have a header in an rpmdb, and content
on the file system. All that RPM does get right -- mostly -- is that if a %post fails,
then the other half of an "upgrade" aka the erasure of the old files will
be skipped if the install fails for any reasons.
This behavior prevents, say, RPM from accidentally rendering a machine
unbbotable if, say, a glibc upgrade fails for whatever reason. But
its purely "disaster avoidance", not anything else. The behavior
you are reporting is exactly what RPM has been doing for years.
> So I need a way to query the database , or look at the output of the initial RPM command to determine which packages failed, and which actually got installed properly - and by properly I mean a package that got installed AND all the script got executed without any error.
The best answer that RPM has atm is this:
Do proper QA on the packaging to make sure scriptlets don't fail.
Write the scriptlets to take into account every failure mode.
Yes this is hard Q and hard to get prefect scripting.
rpm -qa --last
that will sort by installation time, and
rpm -qa --dupes
each of which helps find the duplicate partially installed/registered
packages from a failed "best effort" attempt to "upgrade".
> Does anyone know of any way for me do determine if the rpm’s got successfully installed (that includes also the script phase) ? Shouldn’t the rpm database contain also that info ? I mean it seems to me that’s a pretty important information , to know if a post install script executed successfully for a certain installation …
The problem here is that "successfully installed" does not have any semantic meaning for
RPM. RPM has only the exit code from a scriptlet, cannot undertake any meaningful --rollback
action based purely on an exit code. E.g. package scriptlets can have huge side-effects that
are opaquely implemented in (possibly buggy) scriptlets.
All that RPM has is a non-zero exit code to indicate "failed to install". And the most useful
behavior that most users expect is "best effort" which is proceeding with all the
rest of the installation as far as possible. Manual intervention is always needed
for "failed to install".
73 de Jeff
Received on Fri Feb 18 20:35:02 2011
- application/pkcs7-signature attachment: smime.p7s