On Feb 18, 2011, at 3:59 PM, Mircea Lemnaru wrote:
> 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
Exactly is the short answer.
The other longer/harder answer called "RPM ACID" or
Transactionally Protected Package Management
TPPM is much harder. You can find details at
look for WP3 which is largely about modeling scriptlet side
effects in a DSL to ensure that there's more than an exit code
that both apt <-> rpm distros can use for scalable/reliable/automated
Please note its all "research" still. My role (as part of Mancoosi WP3)
is to try to get as much as possible of the "research" into "production"
over the next/last 3-4 months of the Mancoosi project. I'm just starting now ...
> 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"." -- this failed to install , non-zero exit code ... is it kept anywhere in the RPMdb ... can I retrieve it after the rpm command finished ?
Persistent scriptlet exit codes are tracked into SRPM headers
(for build scriptlets) and into an rpmdb for install scriptlets
in @rpm5.org iirc. I've forgot what I implemented, its
kinda unnecessary because ...
... knowing the exit code from a package scritlet persistently just reminds you of what
you likely already know:
You lose because some package failed to install and you have to clean up the mess.
> 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 installed ?
The very best approach (and what was expected of RPM originally) is
to do the QA carefully and appropriately. RPM makes it really easy
to set up chroot's and test! test! test! your packages.
It's a bit harder than it appears because there's all sorts of
silly failure cases like
A meteor crashed through the CPU while RPM was installing.
but all it takes is some sane judgement calls on what the obvious
failure modes that a typical user will experience.
There's less than 10 types of install/upgrade/erase failures (9 iirc, but I've forgotten)
that need to be tested. Once you get those in place, stare at your scriptlets
looking for possible failure cases.
That's basically "RPM package management" in a nutshell. Never been any different.
73 de Jeff
Received on Fri Feb 18 22:14:23 2011
- application/pkcs7-signature attachment: smime.p7s