First of all tanks for the quick answer
You are saying that: "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
rest of the installation as far as possible. Manual intervention is always
for "failed to install"." -- this failed to install , non-zero exit code ...
is it kept anywhere in the RPMdb ... can I retrieve it after the rpm command
I mean I have these 2 packages, say pkg1 and pkg2. pkg1 fails to install
because a wrong script but pkg2 is just fine. Say I am executing "rpm -i
pkg1 pkg2". It fails with an error that %post script from pkg1 failed but
pkg2 has been succesfully installed. At this point I am looking for a way to
know which one / if any of the two packages were successfully installed ...
rpm -qa | grep pkg1 shows all OK ... so I cannot determine from that output
what I need ...
Could there be a way for me to parse the output of the rpm command to
determine from that that the failure is comming from a script , and also
that it only affects one package so I can assume pk2 was successfully
On Fri, Feb 18, 2011 at 9:34 PM, Jeff Johnson <firstname.lastname@example.org> wrote:
> 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
> 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
> by the package with the failing %post script. But the database registration
> 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.
> Meanwhile, there's
> 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
> for "failed to install".
> 73 de Jeff
Received on Fri Feb 18 22:00:17 2011